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ABSTRACT 

To  address  long  standing  problems  with  modelling  and  simulation,  the  US  Department 
of  Defence  through  the  Defense  Modeling  and  Simulation  Office  (DMSO)  has  initiated 
a  comprehensive  series  of  programs.  These  programs  aim  to  promote  interoperability, 
code  and  model  reuse,  data  standardisation,  common  conceptual  models  of  military 
operations,  and  Validation,  Verification  &  Accreditation  (W&A),  among  other 
important  issues,  through  a  Common  Technical  Framework.  A  key  issue  for  Australia 
is  the  means  of  networking  simulators  together.  The  US  DoD  has  mandated  the  High 
Level  Architecture  (HLA)  which  has  technical  advantages  over  the  previous  standard. 
Distributed  Interactive  Simulation  (DIS).  The  advantages  and  disadvantages  of  each 
approach  are  discussed  in  the  Australian  context.  Other  related  programs  such  as  the 
Synthetic  Environment  Data  Representation  and  Interchange  Specification  (SEDRIS), 
Conceptual  Models  of  Mission  Space,  Master  Environment  Library,  Data  Engineering, 
and  W&A  programs  are  discussed  in  the  Australian  context.  The  authors  recommend 
a  cautious  approach  to  the  introduction  of  HLA  into  the  ADO  following  the  US 
experience.  Through  appropriate  Defence  Exchange  Agreements  the  ADO  can  work 
with  the  US  and  our  other  allies  (particularly  the  UK)  to  ensure  that  ADF  in-service 
training  systems  will  migrate  to  HLA  while  retaining  interoperability. 
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Executive  Summary 

To  address  long  standing  problems  with  modelling  and  simulation,  the  US  through  the 
Defense  Modeling  and  Simulation  Office,  has  initiated  a  comprehensive  series  of 
programs.  These  programs  aim  to  promote  interoperability,  code  and  model  reuse, 
data  standardisation,  common  conceptual  models  of  military  operations,  and  W&A, 
among  other  important  issues,  through  a  Common  Technical  Framework. 

A  key  issue  for  Australia  is  the  means  of  networking  simulators  together.  The  US  DoD 
has  mandated  the  High  Level  Architecture  (HLA)  which  has  technical  advantages  over 
the  previous  standard.  Distributed  Interactive  Simulation  (DIS).  HLA  provides  greater 
flexibility  compared  to  the  rigid  requirements  to  achieve  DIS  compliance.  However  this 
flexibility  can  also  be  a  disadvantage  since  all  participating  simulations  must  agree  on 
which  information  to  interchange.  This  limits  those  players  wanting  to  interoperate  to 
agree  before  hand  on  such  specifications,  and  may  compromise  the  open 
interoperability  that  is  a  key  feature  of  DIS. 


The  Australian  Defence  Organisation  (ADO)  is  moving  towards  Advanced  Distributed 
Simulation  to  enhance  its  training  capability  and  is  gaining  experience  with  DIS. 
Should  the  ADO  consider  HLA  for  its  simulators  and  simulations  or  persist  with  DIS? 
This  document  addresses  these  issues  from  an  Australian  perspective. 

Apart  from  HLA,  DMSO  has  introduced  various  other  related  programs  in  an  attempt 
to  simplify  the  development  of  models  and  simulation.  The  Synthetic  Environment 
Data  Representation  and  Interchange  Specification  (SEDRIS),  Conceptual  Models  of  the 
Mission  Space,  Master  Environment  Library,  and  Data  Engineering  programs  are 
discussed  in  the  Australian  context.  Verification,  Validation  and  Accreditation  (W&A) 
is  another  important  issue  for  Australia  to  consider  in  developing  models  and 
simulations  for  defence  purposes. 

Australia  has  recently  established  the  Australian  Defence  Simulation  Office  (ADSO)  to 
provide  policy  guidance,  coordination,  and  to  foster  collaboration  across  Defence, 
industry,  and  through  international  organisations  such  as  the  Simulation 
Interoperability  Standards  Organisation  (SISO)  and  the  International  Simulation 
Advisory  Group  (ISAG). 

For  real  time,  Australian  Defence  Force  (ADF)  military  tactical  simulators  (especially 
those  to  be  used  primarily  for  training),  the  authors  recommend  DIS  as  the  current 


networking  standard.  Such  simulators  require  the  flexibility  to  interoperate  with  other 
simulators,  but  it  may  not  be  known  in  advance  (at  the  time  of  development  and 
deployment)  with  which  other  simulators  they  might  interoperate.  The  advantage  of 
DIS  is  that  all  DIS-enabled  simulators  can  interoperate.  With  HLA,  the  exact  data 
transfer  mechanism,  the  FOM,  must  all  be  agreed  in  advance.  It  is  necessary  to  know 
with  which  simulators  you  wish  to  network.  If  HLA  is  deemed  to  be  absolutely 
necessary  as  the  networking  architecture,  then  the  SISO  standard  Real  time  Platform 
Reference  Federation  Object  Model  (RPR-FOM)  should  be  specified. 

For  research  projects  and  simulations  used  for  analysis,  which  can  be  designed  to 
network  with  other  simulations  known  in  advance,  the  new  HLA  may  be  preferred. 
The  Virtual  Ship  Project  is  an  excellent  example  of  a  DSTO  research  project,  where  the 
use  of  HLA  is  ideal.  Since  the  interoperability  can  be  planned  ahead,  the  FOM  can  be 
tailor-made  to  suit  the  application. 

HLA  is  new  and  exciting  technology  that  will  ultimately  offer  many  advantages  over 
DIS.  It  is  an  excellent  research  area  for  DSTO,  with  its  long  tradition  of  M&S,  to 
investigate  in  the  laboratory  environment.  An  Australian  Defence  Organisation  FOM 
does  not  exist  and  should  not  be  developed  until  agreement  is  reached  on  likely  allied 
Nation  projects  with  which  Australia  wishes  to  interoperate  (eg  BFTT).  Therefore,  it  is 
highly  premature  to  mandate  its  use  for  the  ADO.  Mandating  HLA  would  compromise 
interoperability  between  ADF  in-service  (or  soon  to  be  in-service)  training  systems  and 
with  the  US  and  other  allies. 

The  authors  recommend  a  cautious  approach  to  the  introduction  of  HLA  into  the  ADO 
following  the  US  experience.  Through  appropriate  Defence  Exchange  Agreements  the 
ADO  can  work  with  the  US  and  our  other  allies  (particularly  the  UK)  to  ensure  that 
ADF  in-service  training  systems  will  migrate  to  HLA  while  retaining  interoperability. 


Authors 


Dr  Peter  Clark 

Air  Operations  Division 

Dr  Peter  Clark  graduated  from  the  Australian  National  University  (ANU)  in 
Canberra  with  a  BSc  (Hons)  in  1978 ,  and  a  PhD  in  Physics  in  1981.  He  joined 
the  Australian  Defence  Department  in  1982.  In  1989  he  was  appointed  for  a 
free  year  period  as  the  Scientific  Adviser  to  Army’s  HQ  Training  Command  in 
Sydney.  In  1994  he  was  appointed  as  a  Senior  Research  Scientist  with  DSTO's 
Air  Operations  Division,  where  he  has  worked  for  the  past  seven  years  on  a 
range  of  topics  involving  simulation  research,  with  an  emphasis  on  Human-in- 
the-Loop  simulation,  intelligent  computer-generated  forces,  and  the 
technologies  associated  with  Advanced  Distributed  Simulation.  Dr  Clark 
served  a  five  year  term  (1993-1997)  as  Panel  Chairman  of  the  TTCP  Technical 
Panel  on  Training  Technology  (HUM-TP2).  Dr  Clark  has  held  the 
appointment  of  Australian  Co-chairman  of  the  International  Simulation 
Advisory  Group  (ISAG)  since  1997. 


Dr  Peter  Ryan 

Air  Operations  Division 

Dr  Peter  Ryan  is  a  Senior  Research  Scientist  with  the  Air  Operations  Division 
ofDSTO.  He  graduated  from  Melbourne  University  with  a  BSc  (Hons,  First 
Class)  in  1975,  and  awarded  a  PhD  from  Melbourne  University  in  1981.  After 
further  research  at  Melbourne  University  and  postdoctoral  work  at  the 
University  of  Massachusetts,  USA  he  joined  DSTO  in  1985  as  a  Research 
Scientist  in  the  Mines  Research  Group.  During  1988-1989  he  was  a  Visiting 
Scientist  at  the  Admiralty  Research  Establishment  (Bincleaves)  at  Weymouth, 
UK.  He  has  an  extensive  background  in  Maritime  Operations  Division  on  the 
modelling  and  simulation  of  ship/mine  encounters  and  the  development  of 
minefield  simulation  models.  In  1998,  he  joined  the  Simulation  &  Human 
Factors  Branch  of  Air  Operations  Division  and  is  now  working  in  the  field  of 
simulation  as  applied  to  both  training  and  also  operational  evaluation.  His 
main  research  interests  are  in  applying  Advanced  Distributed  Simulation 
technology  to  assist  Navy  with  their  training  requirements. 


Dr  Lucien  Zalcman 

Air  Operations  Division 

Dr  Lucien  Zalcman  graduated  from  Melbourne  University  with  a  BSc  (Hons.) 
in  1973.  He  was  awarded  a  PhD  in  Physics  from  Melbourne  University  in 
1980.  He  also  completed  a  Graduate  Diploma  in  Computing  Studies  at  RMIT 
graduating  in  1987.  During  the  period  1980  -  1984  he  worked  as  an 
Experimental  Officer  at  the  CSIRO  Division  of  Mineral  Chemistry  carrying 
out  research  into  lead  acid  batteries  for  electric  vehicles.  He  joined  DSTO  in 
1984  as  an  Information  Technology  Officer  in  the  Computer  Centre  at  the 
Aeronautical  Research  Laboratory.  In  1992  he  was  employed  as  a  Senior 
Professional  Officer  in  Air  Operations  Division  of  AMRL  specialising  in  the 
field  of  Distributed  Interactive  Simulation.  He  was  promoted  to  Senior 
Research  Scientist  in  1998. 


Contents 


1.  INTRODUCTION . 1 

2.  DISTRIBUTED  INTERACTIVE  SIMULATION . 2 

2.1  Description  of  DIS . 2 

2.1  DIS  Standards . . . 3 

2.1.1  The  Entity  State  PDU . 4 

2.1.2  Entity  Interaction  PDUs . 5 

2.2  Advantages  of  DIS . 5 

2.3  Disadvantages  of  DIS . 6 

3.  HIGH  LEVEL  ARCHITECTURE . 6 

3.1  HLA  Description . 6 

3.2  HLA  Standardisation . 7 

3.3  RTI  Services . 8 

3.4  Advantages  of  HLA . 9 

3.5  Disadvantages  of  HLA . 9 

3.6  General  Issues  with  DIS  and  HLA . 10 

4.  MIGRATION  TO  HLA . 10 

4.1  DIS  /  HLA  Gateway . 11 

4.2  Middleware  Approach . 12 

4.3  Native  HLA  Integration . 12 

5.  DIS/HL A  FOR  ADF  SIMULATION  PROJECTS . 12 

5.1  Maritime  Warfare  Training  System  Pro j  ect . 12 

5.2  Virtual  Air  Environment . 14 

5.3  DSTO's  Virtual  Ship  Project . 17 

5.4  Synthetic  Environment  Research  Facility . 17 

5.5  DSTO's  EXC3ITE  Project . 17 

5.6  DSTO  Simulation  Hub . 18 

5.7  Other  ADF  Projects . 19 

5.8  Australian  Military  Platforms  Included  in  SISO  DIS  Enumerations . 19 

5.8.1  FFG  and  DDG  Enumerations . 19 

5.8.2  Oberon  Submarine  Enumerations . 20 

5.8.3  Other  Australian  Enumerations . 20 

5.8.4  Other  Enumerations  Required  for  DIS  Compliance . 22 

6.  FURTHER  DMSO  INITIATIVES . 22 

6.1  SEDRIS . 22 

6.1.1  SEDRIS  Technical  Components . 23 

6.1.2  SEDRIS  Objectives  and  Deliverables . 24 

6.1.3  Standardisation  of  SEDRIS . 25 

6.2  Conceptual  Models  of  the  Mission  Space . 26 

6.2.1  US  DoD  Implementation  of  CMMS . 26 

6.2.2  CMMS  for  Australia . 27 

6.3  Master  Environment  Library . 27 

7.  VERIFICATION,  VALIDATION  AND  ACCREDITATION . 28 

7.1  W&A  Descriptions . 28 


7.2  V erif  ication  and  V alidation . 29 

7.3  Accreditation . . 

7.4  Other  W  &  A  Issues . 31 

7.4.1  Cost  of  W& A . 31 

7.4.2  Data  W&C . 31 

7.5  W &A  for  N etworked  Simulations . 32 

7.5.1  Definitions  of  Interoperability . 32 

7.5.2  DIS  Test  Suite . 32 

8.  AUSTRALIAN  M&S  FUTURE  STRATEGY . 33 

8.1  Australian  Defence  Simulation  Office  (ADSO) . 34 

8.2  Defence  M&S  -  The  Way  Ahead . 34 

9.  SIMULATION  INTEROPERABILITY  STANDARDS  ORGANISATION  (SISO) ...  36 

9.1  Broadened  Participation . 37 

9.2  Standards  Development  Process . 37 

9.3  Workshops  and  Conferences . 38 

9.4  Vision  for  SISO . 39 

10.  INTERNATIONAL  SIMULATION  ADVISORY  GROUP . 39 

10.1  Formation  of  IS  AG . 39 

10.2  ISAG  Aims  and  Achievements . 40 

11.  DISCUSSION . 41 

11.1  IEEE  Standardisation . 42 

11.2  Cost  and  Risk . 42 

11.3  Interoperability  with  Allies . 42 

11.4  Interoperability  within  Australia . 43 

11.5  Lack  of  COTS  Support . 43 

11.6  Recommendations . 43 

12.  CONCLUSIONS . 44 

13.  REFERENCES . 45 

14.  GLOSSARY  OF  ACRONYMS . 48 

15.  ACKNOWLEDGMENTS . 50 

APPENDIX  A:  SISO  WORKSHOP  FORA . 51 

A.l.  Analysis  Forum  ( ANL) . 51 

A.2.  Research,  Development,  and  Engineering  Forum  (RDE) . 51 

A.3.  Test  and  Evaluation  Forum  (TE) . 51 

A.4.  Training  Forum  (TRAINING) . 52 

A. 5.  Specialty  Area  Tracks . 52 

APPENDIX  B:  ISAG  CHARTER  AND  LIST  OF  NATIONS . 61 

B. l.  AIM  OF  THE  ISAG . 61 

B.2.  FURTHER  OBJECTIVES  OF  THE  ISAG . 61 

B.3.  APPOINTMENT  OF  NATIONAL  POINTS  OF  CONTACT  (POCs) . 61 

B.4.  APPOINTMENT  OF  CO-CHAIRMEN . 61 

B.5.  MEMBERSHIP . 61 

B.6.  NATIONS  AND  ORGANISATIONS  ASSOCIATED  WITH  ISAG . 62 


APPENDIX  C:  GLOSSARY  OF  TERMS  AND  ACRONYMS . 63 

Cl.  REFERENCES  FOR  APPENDIX  DEFINITIONS . 76 


DSTO-GD-0255 


1.  Introduction 

In  her  presentation  [1]  at  the  17th  Interservice  /Industry  Training  Systems  and 
Education  Conference  (I/ITSEC)  in  1995,  Dr  Anita  Jones,  then  Director  of  the  US 
Defense  Modeling  and  Simulation  Office  (DMSO)  commenced  her  keynote  address 
with  the  remark  that  US  Department  of  Defense  (DoD)  simulations: 

•  are  built  separately  from  scratch  for  each  user  community, 

•  take  too  long  to  build, 

•  cost  too  much  to  build  and  to  operate, 

•  have  not  been  verified,  validated,  and  accredited, 

•  do  not  use  operational  C3I  systems, 

•  can  be  used  in  concert  only  with  difficulty, 

•  rarely  reuse  data  among  simulations  (eg.,  environmental),  and 

•  can  rarely  interoperate  with  instrumented  ranges. 

To  address  these  issues,  DMSO  initiated  a  comprehensive  series  of  programs  aimed  at 
promoting  interoperability,  code  and  model  reuse,  data  standardisation,  and  W&A, 
among  other  important  issues,  through  a  Common  Technical  Framework. 

A  key  issue  for  Australia  is  the  means  of  networking  simulators  together.  Advanced 
Distributed  Simulation  technologies  are  changing  the  way  in  which  military  forces 
train  and  rehearse  for  missions.  By  connecting  many  simulators  into  a  shared  virtual 
world,  technologies  such  as  Distributed  Interactive  Simulation  (DIS)  can  increase 
training  effectiveness  [2].  DIS  has  been  very  successful  in  this  role  but  has  shown 
deficiencies  in  its  scalability  because  of  the  broadcast  technique  across  many 
computing  nodes  in  a  DIS  exercise  and  in  its  de  facto  restriction  to  real  time  platform 
level  simulation. 

The  US  DoD  has  mandated  the  High  Level  Architecture  (HLA),  which  will  address 
these  deficiencies.  Whereas  DIS  requires  compliance  to  a  standard  Protocol  Data  Unit 
(PDU)  set,  HLA  allows  each  federate  to  specify  what  information  it  will  generate  and 
what  data  it  receives.  However,  all  participating  federates  must  agree  on  which 
information  to  interchange.  This  then  limits  those  players  wanting  to  interoperate  to 
agree  before  hand  on  such  specifications,  and  reduces  to  a  degree  the  open- 
interoperability,  which  is  a  key  feature  of  DIS. 

The  Australian  Defence  Organisation  (ADO)  is  moving  towards  Advanced  Distributed 
Simulation  to  enhance  its  training  capability  and  is  gaining  experience  with  DIS. 
Should  the  ADO  consider  HLA  for  their  simulators  and  simulations  or  persist  with 
DIS?  This  document  addresses  these  issues  from  an  Australian  perspective. 

Apart  from  HLA,  DMSO  has  introduced  various  other  related  programs  in  an  attempt 
to  simplify  the  development  of  models  and  simulation.  These  will  also  be  discussed  in 
the  Australian  context. 
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2.  Distributed  Interactive  Simulation 

2.1  Description  of  DIS 

Distributed  Interactive  Simulation  (DIS)  is  a  netivorking  protocol  standard  that  provides  a 
method  of  communicating  entity  state  and  other  information,  such  as  electronic 
warfare,  through  Protocol  Data  Units  (PDUs).  DIS,  developed  from  the  US  Army's 
SIMNET  [3]  program,  was  under  development  for  about  10  years  [4  -  6],  and  is  now 
considered  to  be  a  fully  mature  simulator/ simulation  networking  technology. 

Since  DIS  is  an  IEEE  standard,  any  simulator  connected  to  the  network  and 
implementing  the  same  version  of  the  DIS  protocols  can  participate  in  a  DIS  exercise. 
However,  DIS  has  resource  issues  in  terms  of  both  network  bandwidth,  and  simulator 
computational  impact,  because  of  the  broadcast  technique  applied  across  many 
computers  in  a  DIS  exercise. 

Third  party  software  products,  such  as  Mak's  VRLirtk  toolkit,  can  interface  a 
simulation  to  the  DIS  network  allowing  it  to  send  and  receive  correctly  formatted 
PDUs  [7].  DIS  is  most  suited  for  connecting  real-time  human-in-loop  simulators. 

The  basic  concepts  of  DIS  are: 

a)  No  central  computer  controls  the  entire  simulation  exercise.  DIS  uses  a  distributed 
simulation  approach  in  which  the  responsibility  for  simulating  the  state  of  each  entity 
(tank,  submarine,  carrier,  aircraft,  missile,  etc.)  rests  with  separate  simulation 
applications  residing  in  computers  communicating  via  a  network. 

b)  Simulation  applications  are  autonomous  and  are  responsible  for  maintaining  the  state  of  one 
or  more  simulation  entities.  The  simulation  application  is  responsible  for  modelling  the 
actions  of  its  entity  or  entities  using  a  high  fidelity  simulation  model.  That  simulation  is 
responsible  for  sending  messages  to  others,  and  as  necessary,  informing  them  of  any 
observable  actions.  All  simulations  are  responsible  for  interpreting  and  responding  to 
messages  of  interest  from  other  simulations,  and  maintaining  a  model  of  the  state  of 
entities  represented  in  the  simulation  exercise.  This  autonomy  principle  enables 
simulation  nodes  to  leave  or  join  an  exercise  which  is  in  progress,  without  disrupting 
the  rest  of  the  simulation. 

c)  A  standard  protocol  is  used  for  communicating  ground  truth  data.  Each  simulation 
application  communicates  the  absolute  truth  about  the  state  of  the  entity  it  controls 
(location,  orientation,  velocity,  articulated  parts  position,  etc.)  to  other  simulations  on 
the  network.  The  receiving  simulation  is  responsible  for  taking  this  ground  truth  data 
and  calculating  whether  the  entity  represented  by  the  sending  simulation  is  detectable 
by  visual  or  electronic  means.  This  perceived  state  of  the  entity  is  then  displayed  to  the 
user  as  required  by  the  individual  simulation. 
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d)  Changes  in  the  state  of  an  entity  are  communicated  by  simulation  applications. 

e)  Perception  of  events  or  other  entities  is  determined  by  the  receiving  application. 

f)  Dead  reckoning  algorithms  are  used  to  reduce  the  communications  processing.  A  method  of 
position/ orientation  estimation,  called  dead  reckoning,  or  "Remote  Entity 
Approximation",  is  used  to  limit  the  rate  at  which  simulations  issue  state  updates  for 
an  entity.  Each  simulation  maintains  a  high  fidelity  model  of  the  entity  it  represents.  In 
addition,  the  simulation  maintains  a  simpler  model  of  its  entity,  which  represents  the 
view  of  that  entity  by  other  simulation  applications  on  the  network  and  is  an 
extrapolation  of  position  and  orientation  state  using  a  specified  dead  reckoning 
algorithm.  On  a  regular  basis,  the  simulation  compares  the  high  fidelity  and  simpler 
models  of  the  entity.  If  the  difference  between  the  two  exceeds  a  predetermined 
threshold,  the  simulation  will  update  the  simpler  model  using  the  information  from  the 
high  fidelity  model.  At  the  same  time,  the  simulation  will  send  updated  information  to 
other  simulations  on  the  network  so  that  they  can  update  their  model  of  the  entity.  If 
an  entity  continues  to  do  the  same  thing  (eg.  straight  and  level  flight  at  constant 
velocity)  the  update  rate  drops  to  a  predetermined  minimum  (heart  beat)  level.  By 
using  dead  reckoning,  simulations  are  not  required  to  report  the  status  of  their  entities 
every  frame. 

2.1  DIS  Standards 

DIS  operates  by  exchanging  data  messages,  known  as  Protocol  Data  Units  (PDU)  on  a 
network  between  simulation  applications.  DIS  has  undergone  the  IEEE  standardisation 
process  three  times: 

•  IEEE  1278-1993  (1993)  [4]:  10  PDUs  to  support  the  appearance  and  movement  of 
entities,  weapons  firing,  ordnance  detonation,  collisions,  and  logistical  resupply  of 
units. 

•  IEEE  1278.1-1995  (1995  [5]:  27  PDUs  to  support  radio  and  tactical  data  links, 
simulation  management,  electronic  warfare  and  laser  interactions  for  smart 
munitions. 

•  IEEE  1278.1a-1998  (1998)  [6]  67  PDUs  with  additional  support  for  emissions,  entity 
information/ interaction,  mine  warfare,  entity  management,  field  instrumentation, 
communications  and  environment. 

With  each  revision,  the  approach  has  been  to  add  new  capability  via  new  PDUs  with 
minimal  changes  to  existing  PDU  structures.  Thus  an  Entity  State  PDU  (ESPDU)  in 
1278.1a  —  1998  is  identical  to  an  ESPDU  in  1278.1  —  1995,  except  for  the  field  specifying 
DIS  version. 

The  IEEE  1278-1993  standard  defined  10  PDU  types: 
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1)  Entity  State 

2)  File 

3)  Detonation 

4)  Service  Request 

5)  Resupply  Offer 


6)  Resupply  Received 

7)  Resupply  Cancel 

8)  Repair  Complete 

9)  Repair  Response 

10)  Collision 


The  IEEE  1278.1-1995  Standard  extended  die  10  DIS  1.0  PDUs  giving  the  following 
27  PDUs: 


A)  Entity  Information 

1)  Entity  State  PDU 

B)  Weapons  Fire 

2)  Fire  PDU 

3)  Detonation  PDU 

C)  Logistics  Support 

4)  Service  Request  PDU 

5)  Resupply  Offer  PDU 

6)  Resupply  Received  PDU 

7)  Resupply  Cancel  PDU 

8)  Repair  Complete  PDU 

9)  Repair  Response  PDU 

D)  Collisions 

10)  Collision  PDU 

E)  Simulation  Management 

11)  Create  Entity  PDU 

12)  Remove  Entity  PDU 


13)  Start/ Resume  PDU 

14)  Stop/ Freeze  PDU 

15)  Acknowledge  PDU 

16)  Action  Request  PDU 

17)  Action  Response  PDU 

18)  Data  Query  PDU 

19)  Set  Data  PDU 

20)  Data  PDU 

21)  Event  Report  PDU 

22)  Message  PDU 

F)  Distributed  Emission  Regeneration 

23)  Emission  PDU 

24)  Laser  PDU 

G)  Radio  Communication  Protocol 

25)  Transmitter  PDU 

26)  Signal  PDU 

27)  Receiver  PDU 


2.1.1  The  Entity  State  PDU 

Information  associated  with  the  entity  is  communicated  in  a  DIS  exercise  through  the 
use  of  an  Entity  State  PDU  (ESPDU).  The  ESPDU  includes  information  necessary  for 
the  receiving  simulation  application(s)  to  represent  the  issuing  entity  in  the  simulation 
applications'  own  simulation. 


The  entity  information  exchanged  between  simulation  applications  includes  the  type  of 
entity,  its  location  and  orientation,  and  how  the  entity  might  appear  to  others. 

a)  Types.  The  simulation  entity  could  be  a  vehicle,  a  building,  a  munition  (eg.  a  missile), 
or  a  cloud  of  smoke.  DIS  requires  that  entities  be  classified  based  on  their  entity  type, 
allowing  a  variety  of  different  entities  to  be  represented. 

b)  Location  and  Orientation.  Sending  the  location  and  orientation  of  an  entity  is  critical 
for  its  correct  representation  by  other  simulations  on  the  network.  Inclusion  of  the 
velocity  and  the  acceleration  parameters  allows  receiving  simulations  to  employ 
higher-level,  higher-accuracy  extrapolation  routines.  Dead  reckoning  parameters  are 
also  transmitted. 
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c)  Appearances.  The  appearance  of  an  entity  can  be  expressed  in  a  number  of  ways. 
Entities  may  be  on  fire  or  smoking.  An  entity  may  emit  engine  smoke  or  have  a  wake 
trailing  behind  in  the  water. 

2.1.2  Entity  Interaction  PDUs 

Throughout  a  simulation  exercise,  the  state  information  associated  with  the 
interactions  that  take  place  between  entities  needs  to  be  exchanged.  Interactions  that 
are  currently  supported  include  weapons  fire,  logistics  support,  and  collisions. 

a)  Weapons  Fire.  When  an  entity  fires  a  weapon,  the  simulation  application  controlling 
the  entity  needs  to  communicate  the  location  of  the  firing  weapon  and  the  type  of 
munition  fired.  The  detonation  of  the  munition  is  also  communicated  by  the  simulation 
application  controlling  the  firing  entity.  Using  the  information  in  the  detonation 
message,  all  simulation  applications  controlling  affected  entities  assess  damage  to  their 
entities. 

b)  Logistics  support.  Certain  services  may  be  modelled  in  a  simulation  exercise  such  as 
resupply  or  repair  of  vehicles.  These  services  are  provided  under  logistics  support. 

c)  Collisions.  In  the  event  that  two  entities  collide,  the  simulations  controlling  the 
entities  must  be  informed  of  the  collision.  Each  simulation  sends  a  message  when  it 
detects  that  its  entity  has  collided  with  another  entity.  Each  simulation  determines  the 
damage  to  its  own  entity  based  on  information  in  the  collision  message. 

2.2  Advantages  of  DIS 

DIS  provides  a  standard  means  of  interconnecting  simulators.  Since  the  format  of  the 
PDU  fields,  together  with  appropriate  data,  has  been  standardised,  many  tools  have 
been  developed,  such  as  scenario  generators,  viewers,  data  loggers,  and  analysis 
toolkits.  One  such  tool.  Modular  Semi  Automated  Forces  (ModSAF),  is  a  scenario 
generator  which  is  used  at  hundreds  of  sites  worldwide  [8].  ModSAF  has  been 
obtained  by  DSTO,  via  TTCP,  and  is  used  by  several  DSTO  Divisions  for  research  and 
development. 

DIS  provides  a  standard  set  of  enumerations  for  entities  and  also  for  weapons,  sensors, 
communication  devices,  environmental  descriptors  and  other  attributes.  This  is  a 
highly  comprehensive  set  that  includes  virtually  the  entire  US  and  former  Soviet 
inventories,  as  well  as  those  of  other  major  nations  such  as  Germany,  France  and  the 
U.K.  Each  country  has  a  unique  identifying  enumeration:  eg.  Australia  (13),  USA  (225), 
Russia  (222).  Compliance  with  those  enumerations  is  mandatory  for  participation  in  a 
DIS  exercise.  The  DIS  enumerations  listings  are  maintained  through  the  Simulation 
Interoperability  Standards  Organisation  (SISO)  [9],  Australian  enumerations  are 
discussed  at  section  5.5,  and  SISO  is  discussed  in  detail  in  section  9. 
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DIS  also  specifies  a  standard  set  of  dead  reckoning  algorithms  that  can  be  used  to 
reduce  network  traffic.  For  example,  dead  reckoning  algorithm  2  specifies  that  the 
entity's  orientation  is  fixed,  and  its  velocity  constant.  Network  packet  formats  are  fully 
defined,  allowing  any  compatible  simulator  or  simulation  to  interoperate  (plug  and 
play).  In  addition,  there  are  many  Commercial-Off-The-Shelf  (COTS)  applications 
(viewers,  loggers,  etc)  that  can  be  used. 

In  addition,  a  DIS  Test  Suite  (DTS)  has  been  developed  (see  section  7.5.2)  to  test  DIS 
compliance  of  simulations  and  simulators  prior  to  participation  in  DIS  exercises,  in  an 
internationally  accredited  automated  environment. 

2.3  Disadvantages  of  DIS 

Whilst  a  standard  protocol,  DIS  may  sometimes  be  viewed  as  rigid  and  inflexible.  In 
response  to  this  criticism,  functionality  has  been  added  to  DIS  by  creating  new  PDUs 
rather  than  by  redesigning  its  architecture  to  provide  more  flexibility.  The  final 
standard  contains  67  PDUs,  most  of  which  contain  redundant  data  fields.  For  strict 
compliance  to  the  DIS  standard,  however,  all  PDU  fields  should  be  correctly 
populated.  This  can  result  in  high  computational  requirements  and  network 
bandwidth  for  very  large  scale  networked  systems. 

DIS  also  has  limited  support  for  entity  aggregation/ deaggregration  and  is  designed 
specifically  for  real  time  platform  level  systems  such  as  manned  flight  simulators. 
However,  these  disadvantages  may  not  be  a  problem  where  manned  military 
simulators  are  being  networked  together  as  training  simulators,  and  the  bandwidth 
requirements  can  be  met. 

DIS  code  is  not  portable/ re-usable  when  using  a  different  DIS  toolkit  from  a  different 
toolkit  supplier.  In  addition,  DIS  compliance  does  not  necessarily  guarantee 
interoperability.  The  fidelity  of  the  models  may  differ  significantly  between 
participating  simulators,  resulting  in  unfair  fights.  Finally,  DIS  may  lack  a  basic  level  of 
security  because  PDUs  are  a  published  standard  -  any  player  can  eavesdrop  the 
exercise  on  the  network. 


3.  High  Level  Architecture 

3.1  HLA  Description 

The  High  Level  Architecture  (HLA)  is  a  methodology  designed  to  support  distributed 
simulation  exercises  [10].  It  has  been  mandated  by  the  US  DoD  as  the  replacement  for 
both  DIS  and  ALSP  (Aggregate  Level  Simulation  Protocol),  a  networking  protocol  used 
for  connecting  wargames  [11].  HLA  development  is  sponsored  by  DMSO. 
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HLA  is  defined  by  the  rules  that  specify  how  simulations  interact  and  the  Run  Time 
Infrastructure  (RTI)  that  provides  the  means  to  exchange  data  during  execution. 
Simulations  are  now  called  federates  and  a  set  of  participating  federates  is  known  as  a 
federation.  The  RTI  (a  software  toolkit)  is  provided  free  by  DMSO  and  can  be 
downloaded  from  the  Internet. 

Each  federate  must  have  an  associated  Simulation  Object  Model  (SOM)  which  describes 
its  data  requirements  for  modelling  entities.  The  SOM  has  a  tabular  format  with  an 
object  class  structure  table  and  an  interaction  class  structure  table.  Object  classes 
typically  refer  to  simulated  physical  entities  such  as  aircraft  and  ships  while  interaction 
classes  describe  the  entity  actions  and  interactions  that  occur  in  simulations  such  as 
weapon  fire  and  communications.  Each  object  class  is  characterised  by  a  set  of 
attributes  describing  its  properties  such  as  position  and  velocity  whereas  each 
interaction  class  is  characterised  by  a  set  of  parameters  such  as  the  result  of  a  munitions 
detonation.  HLA  supports  a  hierarchical  class  structure  although  not  allowing  multiple 
inheritance. 

To  form  a  group  of  participating  federates  known  as  a  federation,  a  Federation  Object 
Model  (FOM),  must  be  developed.  This  FOM  has  the  same  structure  as  the  SOMs  and 
identifies  the  attributes  and  interactions  supported  by  the  federation. 

HLA  provides  for  interaction  between  different  types  of  systems  such  as  real-time 
simulations  and  event-stepped  wargames.  The  RTI  Time  Management  services  (see 
Section  3.3)  have  been  designed  to  handle  interactions  between  both  logical  time  and 
real  time  systems. 

Whereas  DIS  specifies  fixed  formatted  PDUs,  HLA  lets  the  user  define  what  data,  in 
what  format,  are  required  to  be  interchanged  among  federation  members.  Thus  HLA 
has  the  potential  to  be  considerably  more  efficient  than  DIS.  Only  the  data  required  to 
support  a  federation  need  be  sent  over  the  network  rather  than  the  redundant  data  sent 
in  the  DIS  PDUs.  Further,  HLA  should  only  send  data  that  has  changed. 

Although  parts  of  HLA  are  going  through  the  IEEE  standardisation  process,  this  is  not 
yet  complete.  HLA  standardisation  is  underway  [12]  -  there  are  three  draft  standards 
(designated  by  the  P) 

•  P1516  -  Framework  and  rules; 

•  P1516.1  -  Federate  interface  specification;  and 

•  P1516.2- Object  Model  Template. 

3.2  HLA  Standardisation 

•  Framework  and  Rules  -  IEEE  Standard  P1516 :  The  HLA  rules  describe  the 
responsibilities  of  federates  (simulations,  supporting  utilities,  or  interfaces  to  live 
systems)  and  federations  (sets  of  federates  working  together  to  support  distributed 
applications).  The  rules  comprise  a  set  of  underlying  technical  principles  for  HLA. 
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For  federations,  the  rules  address  the  requirement  for  a  Federation  Object  Model 
(FOM),  object  ownership  and  representation,  and  data  exchange.  For  federates,  the 
rules  require  a  Simulation  Object  Model  (SOM),  time  management  in  accordance 
with  the  HLA  Runtime  Infrastructure  (RTI)  time  management  services,  and  certain 
mandatory  functionality  and  constraints  on  attribute  ownership  and  updates. 

•  Federate  Interface  Specification  -  IEEE  Standard  P1516.1:  In  HLA,  federates 
interact  with  a  Run  Time  Infrastructure  (analogous  to  a  special-purpose  distributed 
operating  system)  to  establish  and  maintain  a  federation  and  to  support  efficient 
information  exchange  among  simulations  and  other  federates.  The  HLA  interface 
specification  defines  the  nature  of  these  interactions,  which  are  arranged  into  sets  of 
basic  RTI  services. 

•  Object  Model  Template  (OMT)  Specification  -  IEEE  Standard  P1516.2:  The  HLA 
requires  simulations  (and  other  federates)  and  federations  to  each  have  an  object 
model  describing  the  entities  represented  in  the  simulations  and  the  data  to  be 
exchanged  across  the  federation.  The  HLA  object  model  template  prescribes  the 
method  for  recording  the  information  in  the  object  models,  to  include  objects, 
attributes,  interactions,  and  parameters,  but  it  does  not  define  the  specific  data  (e.g., 
vehicles,  unit  types)  that  will  appear  in  the  object  models. 

3.3  RTI  Services 

The  RTFs  primary  function  is  that  of  a  data  distribution  mechanism.  Federates  send 
information  through  the  RTI,  which  distributes  the  information  to  the  appropriate 
parties.  The  RTI  does  not  maintain  information  about  the  state  of  the  federation  nor 
does  it  handle  any  semantics  associated  with  the  interaction  between  the  federates, 
such  as  what  coordinate  system  to  use,  what  happens  during  a  collision,  or  how  to 
dead-reckon  remote  vehicles.  Also,  the  RTI  does  not  specify  die  exact  byte  layout  of 
data  sent  across  the  network. 


The  RTI  provides  a  common  set  of  services  to  the  federates.  They  can  be  divided  into 

six  categories: 

1.  Federation  Management:  Handles  the  creation,  dynamic  control,  modification,  and 
deletion  of  a  federation  execution. 

2.  Declaration  Management:  Enables  federates  to  declare  to  the  RTI  their  desire  to 
generate  (publish)  and  receive  (subscribe/ reflect)  object  state  and  interaction 
information.  Federates  can  subscribe  to  only  the  objects  they  want  (or  have  the 
capability)  to  receive,  e.g.  tanks  might  need  only  data  pertaining  to  ground 
movement,  or  airplanes  might  need  only  data  pertaining  to  flight  activities 

3.  Object  Management:  Enables  the  creation,  modification,  and  deletion  of  objects  and 
interactions.  These  services  comprise  most  of  the  network  traffic  during  runtime. 

4.  Oivnership  Management:  Allows  federates  to  transfer  ownership  of  object  attributes 
to  other  participants  in  the  simulation. 

5.  Time  Management:  Provides  useful  services  for  setting,  synchronizing,  and 
modifying  simulation  clocks.  Time  Management  services  are  tightly  coupled  with 
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the  Object  Management  services  so  that  state  updates  and  interactions  are 
distributed  in  a  timely  and  ordered  fashion. 

6.  Data  Distribution  Management:  Federates  can  provide  conditions  governing  when  to 
start  or  stop  transmitting  and  receiving  certain  pieces  of  data. 

The  first  four  of  these  broadly  provide  similar  functionality  to  the  DIS  Entity 
Information,  Entity  Management,  and  Simulation  Management  PDUs  although  with  a 
superior  architecture.  The  Time  Management  and  Data  Distribution  Management 
services  have  no  equivalence  in  DIS  which  implicitly  assumes  real  time  interaction 
among  time-synchronised  systems  and  a  broadcast  mechanism  for  data  distribution. 
These  RTI  services  provide  advantages  over  traditional  DIS. 

3.4  Advantages  of  HLA 

HLA  attempts  to  overcome  the  deficiencies  noted  with  DIS,  with  the  federation 
members  defining  in  advance  what  data  need  to  be  sent  to  the  network  via  HLA's 
publish/  subscribe  mechanism.  It  also  provides  greater  functionality  -  any  attribute  can 
be  dead  reckoned  and  any  logical  coordinate  system  can  be  used  instead  of  the  3D  DIS 
geocentric  system. 

HLA  supports  both  real  time  and  logical  time  management.  It  also  allows  entity 
aggregation  and  deaggregration.  This  enables  interaction  between  both  virtual  and 
constructive  simulations  that  may  use  non  real  time  and  employ  aggregrate  units  such 
as  battalions  rather  than  single  platforms. 

The  main  advantage  of  HLA  is  that  it  reduces  the  required  bandwidth,  since  only  the 
required  data  is  transmitted.  In  addition,  further  reductions  in  bandwidth  use  are 
possible  since  users  have  the  freedom  of  defining  when  attributes  should  be  updated. 

A  further  advantage  of  HLA  is  that  since  data  broadcast  is  FOM-specific,  it  will  have 
an  automatic  level  of  security:  interested  parties  will  not  be  able  to  interpret  these  data 
on  the  network  without  knowledge  of  the  FOM  data  content  and  formats. 

3.5  Disadvantages  of  HLA 

As  discussed,  HLA  is  far  more  flexible  than  DIS  -  however  this  flexibility  can  also  be  its 
weakness:  unless  all  federates  agree  on  a  FOM  they  will  not  be  able  to  interoperate 
even  though  they  are  HLA-compliant.  Thus  HLA  compliance  will  not  guarantee 
interoperability,  due  to  the  requirement  to  agree  on  a  specific  FOM  beforehand. 

Each  FOM  needs  its  own  separate  set  of  enumerations  which  are  provided  as  standard 
in  DIS.  Dead  reckoning  algorithms  must  be  developed  as  required  instead  of  using  the 
standard  DIS  set.  Moreover,  since  each  FOM  will  be  unique,  FOM-specific  viewers, 
loggers,  and  analysis  toolkits  must  be  developed.  Such  tools  are  not  presently  available 
as  COTS  software,  and  must  be  individually  created. 
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Due  to  FOM  dependence,  HLA  compliance  will  not  guarantee  that  two  simulators  can 
talk  to  each  other.  To  use  an  analogy  between  simulation  interoperability  and  normal 
human  communication:  with  DIS  all  systems  speak  the  same  language,  eg.  English, 
with  the  same  vocabulary  and  syntax.  In  contrast,  extending  the  analogy,  HLA 
compliance  will  only  mean  that  each  system  has  agreed  to  use  spoken  language  for 
communication,  so  one  system  will  use  English,  another  Russian  etc.  Each  system  will 
be  sending  HLA  packets,  or  words  in  the  human  communications  analogy,  but  these 
packets  will  be  formatted  differently.  An  English  speaker  and  a  Russian  speaker  each 
use  spoken  language  but  cannot  communicate  (interoperate)  because  of  language 
differences. 

The  need  for  Reference  ROMs  has  been  proposed  to  assist  with  conversion  of  systems  to 
HLA  and  to  further  promote  interoperability.  The  Real-Time  Platform  Reference  FOM 
(RPR-FOM)  has  been  developed  for  real-time  platform  level  federations  to  facilitate  the 
transition  for  DIS  compatible  simulations  to  HLA  [13].  The  RPR-FOM  is  a  HLA 
description  of  the  DIS  protocols.  It  will  eventually  support  the  functionality  contained 
in  DIS  2.1.4  (the  final  standardised  version  of  DIS)  and  is  supplied  with  both  the  MaK 
VR-Link  toolkit  and  the  Institute  of  Simulation  and  Training  (1ST)  DIS/ HLA  Gateway 
(see  section  4.1).  It  is  also  a  Simulation  Interoperability  Standards  (SISO)  standard  (see 
section  9).  However,  the  RPR-FOM,  which  maps  the  DIS  PDUs  to  HLA,  currently 
supports  DIS  2.0.4  only,  and  will  not  support  DIS  2.1.4  until  at  least  late  2000. 

It  should  be  noted  that  HLA  compliance  testing  involves  testing  against  one's  own 
system  -  the  only  system  guaranteed  to  be  interoperable. 

3.6  General  Issues  with  DIS  and  HLA 

Commonality  of  the  synthetic  environment  is  a  fundamental  requirement  for 
distributed  simulation.  However  neither  DIS  nor  HLA  ensures  correlation  of  the 
different  databases.  One  approach  with  HLA  [14]  is  to  develop  a  run-time  terrain 
component  interface  that  allows  a  simulation  to  use  the  terrain  database  independent 
of  the  actual  terrain  representation. 

Voice  and  Data  link  communications  can  be  achieved  in  DIS  using  the  Radio 
Communications  PDU  family.  HLA  implementations  will  need  to  develop 
communications  classes  to  achieve  the  same  functionality. 

4.  Migration  to  HLA 

Increasing  demands  are  being  put  on  legacy  simulators  to  upgrade  to  HLA.  For 
example,  the  USN  is  considering  migration  options  for  its  legacy  Battle  Force  Tactical 
Training  (BFTT)  Program  from  DIS  to  HLA  [15].  However,  HLA  remains  a  developing 
standard  (and  technology)  and  to  be  interoperable  with  current  Commercial-Off-The- 
Shelf  (COTS)  products,  DIS  compliance  is  still  required. 
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Because  of  the  US  DoD's  mandating  of  HLA,  considerable  effort  has  been  applied  to 
provide  a  means  of  enabling  DIS-compliant  systems  to  upgrade  to  HLA.  Migration  of 
DIS  to  HLA  is  available  via: 

a)  a  gateway  which  translates  between  DIS  PDUs  and  HLA  Services  in  both  directions 
in  real-time  [16]; 

b)  middleware  which  resides  in  the  simulator  [17];  or 

c)  native  HLA  integration  which  entails  software  redesign  to  conform  to  the  HLA 
requirements  [18]. 

Each  approach  has  associated  costs  and  risks  as  discussed  below.  These  approaches 
have  been  previously  outlined  for  the  Royal  Australian  Navy  with  respect  to  Project 
Sea  1412  [19]. 

4.1  DIS /HLA  Gateway 

A  DIS/HLA  gateway  converts  between  DIS  PDUs  and  HLA  Services  in  both  directions 
in  "real-time"  whilst  the  simulation  exercise  is  in  progress.  This  is  the  easiest  way  to 
implement  HLA  compliance,  as  there  is  no  modification  required  in  the  DIS  compliant 
legacy  simulator  other  than  placing  the  gateway  "box"  between  the  legacy  simulator 
and  the  HLA  network.  However,  it  is  likely  to  result  in  the  greatest  additional  latency. 
Where  the  benefits  of  HLA  (interaction  with  constructive  simulations,  reduced 
broadcasting  of  data,  etc)  are  not  required,  the  gateway  remains  the  most  effective  way 
to  retain  the  benefits  of  interoperability  by  DIS,  whilst  still  having  the  ability  to  connect 
via  HLA. 

One  example  of  a  DIS/HLA  Gateway,  from  the  Institute  of  Simulation  and  Training 
(1ST),  provides  a  path  for  legacy  systems  to  interoperate  with  HLA  federations  using 
the  RPR-FOM  [20].  The  Gateway  is  a  stand-alone  interface  node  connecting  DIS  (2.0.3, 
2.0.4,  IEEE  1278.1,  IEEE  1278.1a)  networks  to  an  HLA  RPR-FOM  federation  execution. 
No  modification  of  the  existing  legacy  system  is  required  because  the  Gateway  is 
stand-alone.  On  the  DIS  side  of  the  Gateway,  PDUs  are  formatted,  sent,  and  received 
according  to  the  protocol.  The  Gateway  receives  these  packets  and  translates  them  at 
two  levels:  (1)  the  DIS  PDU  data  packets  are  converted  into  the  data  formats  defined  in 
the  RPR-FOM,  and  (2)  the  sequence  of  packets  are  translated  into  corresponding  RTI 
service  invocations. 

The  Gateway  performs  a  similar  conversion  of  data  received  from  the  HLA  federation 
execution.  The  Gateway  must  also  perform  those  functions  for  which  there  are  no  DIS 
analogues.  These  functions  include  creating,  destroying,  joining,  and  resigning 
federations  and  publishing  and  subscribing  to  the  RPR-FOM  classes. 
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4.2  Middleware  Approach 

In  the  middleware  approach,  the  application  uses  a  higher  level  (abstraction)  interface, 
which  can  be  used  for  both  DIS  and  HLA  services.  Since  the  topmost  HLA  software 
layer  works  in  parallel  with,  or  replaces,  the  equivalent  DIS  software  layer,  latency  is 
reduced  compared  to  the  gateway  option. 

MaK  Technologies'  VR-Link  now  supports  both  DIS  and  HLA  (using  the  RPR-FOM) 
[7],  If  VR-Link  is  already  being  used,  HLA/ DIS  support  is  selected  via  a  compile  time 
switch  and  minimal  change  to  a  simulator's  source  code.  Utilising  this  toolkit  for  HLA 
compliance  is  an  attractive  proposition  because  VR-Link  is  already  widely  used  in  the 
simulation  industry  and  much  of  the  DIS/ HLA  code  maintenance  is  indirectly  shifted 
to  MaK  Technologies. 

4.3  Native  HLA  Integration 

A  native  integration  is  a  tight  coupling  between  the  HLA  and  simulator  code. 
Throughout  the  simulator  the  DIS  paradigm  is  replaced  by  the  more  modem,  object 
oriented,  philosophy  of  HLA.  This  approach  should  provide  all  the  benefits  of  HLA 
but  at  the  highest  initial  and  continuing  cost.  Since  the  interface  code  is  FOM 
dependant,  considerable  software  development  and  associated  maintenance  will  be 
required,  and  backward  DIS  compatibility  is  unlikely  unless  a  FOM  similar  to  the  RPR- 
FOM  is  used. 


5.  DIS/HLA  for  ADF  Simulation  Projects 


The  Australian  Defence  Force  is  essentially  presented  with  the  choice  between  DIS  and 
HLA  as  the  means  to  provide  simulator  interoperability.  Each  project  is  essentially 
considering  the  way  ahead  with  respect  to  DIS/HLA  on  a  case  by  case  basis.  The 
formation  of  an  Australian  Defence  Simulation  Office  (ADSO)  and  the  promulgation  of 
an  Australian  Defence  Simulation  Master  Plan,  will  shortly  provide  improved 
guidance.  Both  the  ADF  and  DSTO  are  developing  distributed  simulation  projects. 
Two  of  the  flagship  projects  for  Navy  and  Air  Force  are  described  below. 

5.1  Maritime  Warfare  Training  System  Project 

Through  Project  SEA  1412,  the  RAN  is  seeking  to  develop  the  Maritime  Warfare 
Training  System  (MWTS)  which  will  initially  link  several  existing  operations  room 
trainers  to  provide  enhanced  command  team  and  tactical  training  for  the  RAN  into  the 
21st  century  [21]. 

In  later  phases  of  die  Project,  an  Australian  wide-area  maritime  simulation  network 
will  be  established.  This  system  could  include  ships  alongside  at  Fleet  Base  East  in 
Sydney  and  Fleet  Base  West  in  Western  Australia,  linked  via  their  on-board  training 
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systems  with  the  wargaming  system  and  ship  models  at  HMAS  WATSON  in  Sydney, 
as  well  as  other  ADF  simulators,  such  as  RAN  helicopter  simulators  and  RAAF  P3C, 
FA-18  and  Airborne  Early  Warning  &  Control  (AEW&C)  simulators,  all  participating 
in  a  common  virtual  scenario.  In  time,  there  is  potential  to  extend  this  environment  to 
include  ships  at  sea,  although  this  requirement  will  create  various  communication 
challenges. 

This  will  provide  training  for  the  two-ocean  based  Navy  (Sydney  and  Perth)  without 
requiring  expensive  co-location  of  assets.  The  MWTS  would  provide  manned  assets, 
instructor  supervision,  and  game  control  and  debriefing,  for  exercises  involving  both 
live  and  simulated  assets  across  a  large  synthetic  operating  area.  The  Maritime  Warfare 
Training  System  is  depicted  in  Figure  1. 


ADF  Siraulafois 


DDG 

MODEL 


ANZAC 

CSTT 


Wargame 

Stations 


FFG 

MODEL 


Figure  1:  Maritime  Warfare  Training  System 


During  later  stages  of  the  development  of  the  MWTS,  DIS  connectivity  would  also 
allow  linkages  to  other  DIS-enabled  Australian  Defence  Force  (ADF)  simulators  such  as 
the  Seahawk  simulator  and  P3C  simulator  (as  examples),  to  participate  in  larger  scale 
combined  exercises  over  a  wide  area  network  (WAN)  on  an  opportunity  basis.  Further 
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in  the  future  a  DIS  capability  will  enable  the  RAN  to  participate  in  international 
simulated  exercises. 

DIS/HLA  interfaces  are  required  for  the  components  that  will  make  up  the  MWTS. 
Considering: 

a)  the  immaturity  of  HLA; 

b)  that  an  upgrade  path  to  HLA  can  be  achieved  via  appropriate  software;  and 

c)  the  maturity  of  DIS; 

it  is  expected  that  DIS  will  be  implemented  for  the  first  Phase  which  comprises  a  Local 
Area  Network  at  HMAS  WATSON  with  a  number  of  participating  simulators. 

The  US  Navy  is  developing  the  Battle  Force  Tactical  Training  (BFTT)  system  that  uses 
distributed  simulation  to  provide  training  for  individual  and  multiple  sets  of  ships. 
BFTT  is  primarily  an  in-port,  shipboard,  combat  system  team  training  capability  that 
operates  by  stimulating/ simulating  shipboard  sensors  and  by  introducing  virtual 
forces  such  as  friendly,  neutral  and  hostile  aircraft,  ships  and  submarines. 

It  is  essential  that  SEA  1412  be  able  to  interoperate  with  BFTT  to  enable  matritime 
coalition  training  in  a  synthetic  environment.  BFTT  is  using  DIS  (rather  than  HLA), 
thus  SEA  1412  will  use  DIS  and  in  conjunction  with  the  BFTT  program,  move  to  HLA 
when  appropriate.  At  such  a  later  stage,  HLA  capability  could  be  added  to  allow 
interoperability  with  external  HLA-compliant  systems.  Thus  later  phases  of  the  MWTS 
may  run  DIS  internally  on  the  FIMAS  WATSON  LAN  and  communicate  externally  via 
HLA.  DSTO  (AOD)  is  cooperating  with  the  USN  BFTT  program  in  outlining  a 
collaborative  research  program  on  issues  associated  with  migration  from  DIS  to  HLA 
[22]. 

A  similar  approach  could  be  adopted  for  the  On  Board  Training  Systems  (OBTS)  which 
will  be  added  to  the  MWTS.  By  specifying  a  DIS/HLA  interface  for  the  OBTS, 
appropriate  interfacing  software  can  provide  either  DIS  or  HLA  as  needs  require. 

5.2  Virtual  Air  Environment 

The  1997  Defence  White  Paper  placed  a  high  priority  on  the  ability  to  integrate 
surveillance  and  intelligence  information  to  detect,  track  and  identify  all  air  and 
maritime  targets  in  Australia's  northern  approaches.  A  number  of  systems  (JORN, 
AEW&C,  Air  Defence  Ground  Environment  (ADGE),  and  the  Air  Command  Support 
Systems  (ACSS)  are  being  acquired  to  meet  the  air  surveillance /  airspace  control/ air 
defence  component  of  this  capability. 

Introduction  of  JORN,  AEW&C  and  a  modem  ground  control  environment  will 
require  a  considerable  increase  in  the  number  of  active  Air  Defence  Controllers. 
However,  the  number  of  F/A-18  missions  available  to  support  ADCON  training  will 
remain  static.  The  significant  investment  in  Air  Defence  and  Airspace  Control  systems 
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must  be  supported  by  comprehensive  simulation  systems  if  operators  are  to  maintain 
at  an  acceptable  level  of  operational  capability. 


The  Virtual  Air  Environment  (VAE)  Project  aims  to  provide  a  framework  within  which 
many  RAAF  training  simulation  activities  would  take  place  [23].  The  VAE  concept 
would  have  applicability  to  a  wide  range  of  ADF  simulation  systems,  to  the  evaluation 
of  operational  capabilities,  and  to  the  development  and  analysis  of  C4I  and  weapons 
systems. 


The  VAE  concept  is  based  on  the  stimulation  of,  and  embedded  simulation  within,  the 
Air  Defence  and  Airspace  Command,  Control  and  Communication  System  (ADAC2S), 
which  will  be  operational  in  the  year  2001.  The  VAE  could  also  be  linked  to  Army  and 
Navy  simulation  systems  to  provide  a  common  environment  for  future  joint  simulation 
activities. 


The  Initial  Development  Phase  of  the  VAE  project  focuses  on  an  application  to  Air 
Defence  Controller  training,  which  integrates  real  assets  (RAAF  Williamtown  Air 
Defence  Controller  Consoles)  and  virtual  simulations  (comprising  Human-in-the-Loop 
(HiL)  and  computer  generated  entities)  in  one  environment,  to  create  a  cost-effective 
virtual  world  training  capability.  Eventually,  this  could  involve  most  of  the  Australian 
Air  Defence  System.  DIS  is  being  used  initially  as  the  networking  protocol. 

Figure  2  shows  the  linkage  between  the  Air  Operations  Division  in  Melbourne 
(supplying  HiL  simulators  and  CGFs)  and  the  Number  3  Control  and  Reporting  Unit 
(3CRU)  based  at  RAAF  Base  Williamtown.  In  the  first  VAE  demonstration  [24]  the 
virtual  world  was  generated  at  DSTO's  Air  Operations  Simulation  Centre  (AOSC)  at 
Fishermens  Bend,  Melbourne.  The  AOSC  was  connected  to  RAAF  Williamtown  via  an 
ISDN  Wide  Area  Network.  Virtual  entities  generated  at  the  AOSC  were  correctly 
observed  in  the  RAAF  Williamtown  radar  system 

This  demonstration  involved  linking  four  systems:  a  human-in-the-loop  F/A-18  flight 
simulator,  two  sources  of  computer  generated  entities  (BattleModel  and  STAGE),  and 
the  operational  Phoenix  display  system  for  Air  Defence  Controllers.  The  first  three 
provide  computer-generated  entities  that  stimulate  the  operational  Air  Defence  System 
to  provide  command  and  control  training. 


An  Air  Defence  Controller,  using  the  real  Air  Defence  System  at  Williamtown,  directed 
the  pilot  of  the  F/A-18  flight  simulator  in  Melbourne  to  intercept  virtual  (computer 
generated)  entities  also  produced  in  Melbourne.  All  entities  were  displayed  on  the  real 
Air  Defence  Controllers'  display  system  in  Williamtown. 


15 


DSTO-GD-0255 


5.3  DSTO's  Virtual  Ship  Project 

DSTO's  Maritime  Operations  Division  is  co-ordinating  a  DSTO-wide  R&D  project  to 
develop  the  Virtual  Ship  [25].  This  project  employs  HLA  as  the  core  technology  to 
connect  modelled  ship  subsystems  such  as  sensors,  weapons,  and  C2  systems  into  an 
integrated  simulation  of  a  naval  vessel.  Potential  applications  of  the  Virtual  Ship 
include  capability  development,  acquisition,  training,  mission  rehearsal  and  tactical 
development.  HLA  compliant  simulation  models  of  sensors,  weapons  and  command 
and  control  system  components  are  currently  under  development. 

The  Virtual  Ship  Architecture  Working  Group  (VSAWG)  is  developing  the  Virtual  Ship 
Architecture  (VSA),  which  is  based  on  HLA.  As  is  required  by  HLA,  significant  effort 
has  been  devoted  to  architectural  design,  with  emphasis  on  the  construction  of  the 
Virtual  Ship  Federation  Object  Model  (VS-FOM).  Another  critical  aspect  of  the  VSA  is 
the  concept  for  federation  execution  management,  and  a  first  version  of  the  Virtual 
Ship  Execution  Manager  (VSEM)  is  nearing  completion. 

5.4  Synthetic  Environment  Research  Facility 

DSTO's  Land  Operations  Division  has  established  the  Synthetic  Environment  Research 
Facility  (SERF)  at  Salisbury  in  South  Australia.  Synthetic  environments  were  built  at 
RAAF  Base  Tindal,  creating  virtual  cockpits  with  aircrew  controls,  instrumentation, 
visuals,  communications  and  data  capture.  This  was  supported  by  the  creation  of  a 
virtual  terrain  and  scenario  generation  integrated  into  real  exercises.  Army  crews  flew 
(Exercise  Phoenix)  a  number  of  simulated  armed  reconnaissance  helicopter  missions, 
as  a  learning  exercise,  resulting  in  significantly  faster  time-to-air  capability  while 
flagging  critical  issues. 

The  SERF  is  playing  a  crucial  role  in  the  support  Project  Air  87  -  the  Australian  Army's 
latest  capability  acquisition  program  -  and  the  development  of  an  Armed 
Reconnaissance  Helicopter  (ARH)  capability.  Using  the  SERF  for  virtual  exercising,  the 
Army  is  gaining  vital  information  on  ARH  capability  before  delivery  of  the  new 
aircraft  in  2004. 

5.5  DSTO's  EXC3ITE  Project 

The  Experimental  C3I  Technology  Environment  (EXC3ITE)  Project  is  producing  an 
enabling  environment  for  experimentation  with  new  technology  and  work  practices  to 
assist  the  ADF  in  improving  its  command  and  control  and  in  evolving  an  enhanced 
C4ISR  capability  [26].  At  the  core  of  EXC3ITE  is  a  high-bandwidth  ATM  network. 
Various  services  will  reside  on  the  network  designed  to  deliver  capability  to  the  users. 
The  primary  technology  being  demonstrated  is  the  use  of  component  architectures  and 
object  brokered  services  that  promise  to  allow  a  more  flexible  and  integrated  solution 
to  the  development  of  end-user  tools  and  applications. 
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EXC3ITE  will  provide  various  services  mostly  related  to  command  and  control 
applications.  It  will  also  include  a  set  of  services  for  simulation  [27]  such  as: 

•  Repositories  of  simulation-related  material  such  as:  terrain  datasets  (for  virtual  and 
constructive  systems);  visual/IR  models  of  entities;  flight  models;  command  agents; 
latency  and  packet-analysers;  datasets,  for  example,  platform  characteristics; 
various  information  and  reference  sources;  lessons  learnt  etc. 

•  Stimulation  services  to  be  used  to  stimulate  a  simulation  with  recorded  data.  The 
data  source  could  be  either  live  (tracks,  weather,  atmospheric/ oceanic  propagation 
conditions,  sea-state  etc.)  or  simulated  from  prior  experimentation  with  the 
capability  to  manipulate  the  data  time  base  and  stimulate  at  appropriate  rates. 

•  Immersive  synthetic  environments  constituting  interactive  systems  of  systems, 
potentially  including  human-in-the-loop. 

•  Translation  services  such  as  coordinate  converters;  DIS  to/from  HLA;  tracks  to/from 
HLA;  suitably  broad-based  or  simulation-service-recommended  FOMs;  RTI 
Interface  Definition  (RID)  files  etc. 

EXC3ITE  will  create  a  prototype  Joint  Synthetic  Environment  that  could  link  existing 
and  emerging  environments  such  virtual  air,  land  and  maritime  platforms;  C4ISR,  EW 
and  Information  Organisation  (IO)  simulations  developed  in  DSTO,  industry  and  by 
our  allies  through  the  use  of  interoperable  standards. 


5.6  DSTO  Simulation  Hub 

DSTO  is  in  the  process  of  setting  up  a  Simulation  Hub.  The  Hub  will  provide 
Simulation  researchers  with  a  comprehensive  picture  of  DSTO  Simulation  research, 
rather  than  the  more  specialised  snapshots  seen  within  any  one  Division.  It  provides 
the  opportunity  to  be  part  of  the  wider  Simulation  community  in  DSTO  and  in 
Australia. 

The  primary  role  of  the  Simulation  Hub  will  be  to  advise  Division  Chiefs  on 

•  strategic  planning  of  Simulation  research  in  DSTO 

•  the  derivation  of  a  DSTO  Simulation  Plan; 

•  coordination  of  DSTO  Simulation  policies,  plans  and  activities  within  broader 
Defence  Simulation  policies,  plans  and  projects; 

•  the  ER&D  plan,  major  Simulation  equipment  and  facility  plans; 

•  the  coordination  of  Simulation  research  efforts  across  DSTO  Divisions  and  to  bring 
wider  scientific  expertise  to  bear  on  difficult  problems; 

It  will  have  a  secondary  role  to: 

•  provide  visibility  of  the  different  Simulation  research  areas  (Focus  Areas)  across  the 
entire  Simulation  R&D  Program. 

•  facilitate  the  exchange  of  ideas  and  concepts  in  Simulation  and  related  fields; 

•  maintain  the  scientific  excellence  of  Simulation  research  by  peer  review; 
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•  enhance  the  interaction  between  Simulation  researchers  at  DSTO  and  those  in  the 
ADF,  TTCP  Groups,  Industry,  Australian  Universities,  and  CSIRO; 

•  maintain  and  develop  the  DSTO  Simulation  skill  base  and  provide  a  broader  base 
for  career  development  of  DSTO  staff  working  in  Simulation  related  research; 

•  promote  the  incorporation  of  Simulation  Requirements  Specifications  at  all  stages 
of  the  Defence  acquisition  process. 

5.7  Other  ADF  Projects 

Whilst  the  MWTC  and  VAE  are  overarching  ADF  projects  for  the  maritime  and  air 
defence  environments,  other  ADF  projects  are  developing  systems  capable  of  being 
linked  to  these  virtual  environments.  The  Army  is  developing  vehicle  simulators.  Navy 
is  developing  and  upgrading  various  helicopter  simulators  and  the  OBTS  for  its  FFGs, 
whilst  Air  Force  is  upgrading  its  flight  simulators  to  include  interoperability  via 
DIS/HLA. 

5.8  Australian  Military  Platforms  Included  in  SISO  DIS  Enumerations 

At  the  request  of  Australia  (Air  Operations  Division,  DSTO),  SISO  updated  (in  1998) 
the  DIS  enumerations  to  include  the  six  Australian  Guided  Missile  Frigates  (FFGs), 
three  Charles  F.  Adams  Destroyers  (DDGs)  and  two  Oberon  class  submarines.  These 
assets  were  designed  and/ or  built  overseas  and  must  be  included  under  the  country  to 
which  a  particular  platform's  design  is  attributed  according  to  the  DIS  1278  IEEE 
standard. 

5.8.1  FFG  and  DDG  Enumerations 

The  FFGs  and  DDGs  are  now  included  under  the  US  asset  listings  with  Australian 
designations  as  listed  in  Table  1. 


Table  1:  Enumerations  for  Australian  DDGs  and  FFGs 


Vessel  Class 

Vessel 

Enumeration 

Descriptor 

DDG 

HMAS  Perth 

1-3-225-4-5-1 

DDG  Perth  (Australia) 

HMAS  Brisbane 

1-3-225-4-5-2 

DDG  Hobart  (Australia) 

FFG 

HMAS  Adelaide 

1-3-225-6-1-1 

FFG  01  Adelaide  (Australia) 

HMAS  Canberra 

1-3-225-6-1-2 

FFG  02  Canberra(Australia) 

HMAS  Sydney 

1-3-225-6-1-3 

FFG  03  Sydney  (Australia) 

HMAS  Darwin 

1-3-225-6-1-4 

FFG  04  Darwin  (Australia) 

HMAS  Melbourne 

1-3-225-6-1-5 

FFG  05  Melbourne  (Australia) 

HMAS  Newcastle 

1-3-225-6-1-6 

FFG  06  Newcastle  (Australia) 

The  enumeration  is  interpreted  as  follows  for  HMAS  Adelaide: 
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•  Kind  -  1  for  platform 

•  Domain  -  3  for  surface 

•  Country  -  225  for  US  (country  of  design) 

•  Category  -  4  for  guided  missile  frigate 

•  Subcategory  -  1  for  Oliver  Perry  class 

•  Specific  -  FFG01  Adelaide  (Australia) 

Note  that  a  new  subclass.  Modified  Charles  F.  Adams,  was  created  to  incorporate  the 
Australian  DDGs.  The  US  Navy  no  longer  has  any  Charles  F.  Adams  class  DDGs  in 
service. 

5.8.2  Oberon  Submarine  Enumerations 

Similarly,  the  two  remaining  in-service  Oberon  class  submarines  are  included  under 
the  UK  assets  as: 

Oberon  Submarines: 

1-4-224-5-2-60  Onslow  (Australia) 

1-4-224-5-2-62  Otama  (Australia) 

5.8.3  Other  Australian  Enumerations 

For  Air  Force,  AOD  had  previously  included  the  Nomad  aircraft  type  (no  longer  in 
service).  These  enumerations  are  listed  in  Table  2.  Other  RAAF  assets  such  as  the  F/A- 
18  and  Fill  are  US-designed  and  do  not  require  distinct  enumerations.  As  new 
Australian  platforms  (eg  A-P3C  and  AEW&C  aircraft)  are  acquired,  specific  DIS 
enumerations  will  need  to  be  assigned. 


Table  2:  Enumerations  for  RAAF  assets 


Kind 

Domain 

Country 

Category 

Subcategory 

Specific 

1 

2 

13 

4 

(Cargo/Tanker) 

0  (other) 

1  (GAF  Nomad) 

1N22B 

2.  N24A 

In  1995,  Australia  (through  AOD,  DSTO)  submitted  and  had  included  the  enumeration 
and  bit-encoded  values  of  Australian  built  vessels  such  as  ANZAC  class  frigates  and 
Collins  class  submarines.  These  assets  are  identifiable  by  using  the  Country 
enumeration  (code  13  for  Australia).  This  will  assist  the  Royal  Australian  Navy  with 
clear  identification  of  assets  for  Project  SEA  1412,  and  will  allow  future  participation  in 
combined  synthetic  exercises.  New  Zealand  vessels  HMNZS  Te  Kaha  and  FIMNZS  Te 
Mana,  built  by  Australia,  will  also  need  to  have  unique  enumerations  allocated. 

Enumerations  for  surface  warfare,  mine  warfare,  and  submarines  are  included  in 
Tables  3, 4, 5,  respectively. 
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Table  3  Enumerations  for  RAN  surface  warfare  vessels 


Cateeo 


6  (Guided 
Missile  Frigate) 
FFG 


Subcatesro 


0  (other) 


1  ANZAC  Class 
(Meko  2000) 


7  Light/Patrol  0  Other 
Craft 


1  Fremantle 
Class  (Large 
Patrol  Craft) 


FFG  150  Anzac 
FFG  151  Arunta 
FFG  152  Warumungu 
FFG  153  Stuart 
FFG  154  Parramatta 
FFG  155  Ballarat 
FFG  156  Toowoomba 
FFG  157  Perth 


1  P  203  Fremantle 

2.  P  204  Warmambool 

3.  P  205  Townsville 

4.  P  206  Wollongong 

5.  P  207  Launceston 

6.  P  208  Whyalla 

7.  P  209  Ipswich 

8.  P  210  Cessnock 

9.  P  211  Bendigo 

10.  P  212  Gawler 

11.  P  213  Geraldton 

12.  P  214  Dubbo 

13.  P  215  Geelong 

14.  P  216  Gladstone 
15  P  217  Bunbu 


50  Frigate  |  0  Other 


Table  4  Enumerations  for  RAN  mine  warfare  vessels 


21 


DSTO-GD-0255 


Table  5:  Enumerations  for  RAN  Collins  Class  Submarines 


Kind 

Domain 

Country 

Category 

Subcategory 

Specific 

1 

4 

13 

4SSG 

(Conventional 
Guided  Missile) 

0  Other 

1  Collins  Class 

1  S  71  Collins 

2  S72Famcomb 

3  S  73  Waller 

4  S  74  Dechaineux 

5  S  75  Sheean 

6  S  76  Rankin 

5.8.4  Other  Enumerations  Required  for  DIS  Compliance 

In  addition  to  the  platforms,  enumerations  in  DIS  are  required  to  describe: 

•  Munitions 

•  Life  forms 

•  Environmental  features 

•  Cultural  features 

•  Supply  descriptors 

•  Radios 

•  Expendables 

•  Sensors  and  Emitters 

These  will  also  need  to  be  included  in  the  DIS  enumeration  database  for  compliance 
with  the  DIS  standards.  For  example,  the  sonar  enumerations  are  sparsely  populated 
compared  to  the  radar  enumerations  since  underwater  warfare  was  not  allowed  for 
until  the  latest  version  of  DIS.  Enumerations  for  sonar  systems  attached  to  RAN  ships 
will  need  to  be  included  for  full  compliance  with  DIS. 


6.  Further  DMSO  Initiatives 


DMSO  has  initiated  several  other  programs  to  simplify  the  modelling  and  simulation 
process.  Similarly  to  HLA,  these  programs  are  aimed  at  promoting  interoperability, 
software  reuse,  and  standardisation.  These  are  generally  less  developed  than  the  HLA 
initiative.  The  most  relevant  of  these  to  Australian  Defence  are  discussed  in  the 
following  sections. 

6.1  SEDRIS 

Common  representation  of  the  physical  environment  is  a  necessary  precondition  for 
interoperability  in  heterogeneous  modelling  and  simulation  (M&S).  The  level  of 
interoperability  achieved  depends  heavily  upon  the  degree  of  consistency, 
completeness  and  unambiguous  definition  of  environmental  data.  No  uniform  and 
effective  standard  mechanism  currently  exists  for  describing,  re-using,  and 
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interchanging  environmental  data  among  M&S  applications.  Additionally,  data 
sharing  rarely  occurs  between  the  operational  and  simulation  communities,  although 
each  community  uses  representations  of  the  same  physical  aspects  of  the  real  world. 

The  Synthetic  Environment  Data  Representation  and  Interchange  Specification 
(SEDRIS)  Project  [28]  is  an  R&D  effort  focused  on  providing  a  pre-runtime  interchange 
mechanism  supporting  the  distribution  of  source  data,  three-dimensional  models  and 
integrated  databases  that  describe  the  physical  environment.  The  capability  to  share 
common  descriptions  of  the  physical  environment  through  a  standard  interface  is  a 
precondition  for  interoperability. 

SEDRIS  is  a  DMSO  funded  activity  to  develop  a  robust  capability  for  environmental 
data  interchange.  The  disparate  nature  of  simulation  interests  in  environmental  data 
must  be  accounted  for,  as  must  the  wide  variety  of  environmental  data  types  required 
to  populate  a  sufficiently  complete  representation  of  the  physical  world  to  meet  M&S 
Community  objectives. 

Support  for  the  operational  domains  of  land,  sea,  air,  and  space  is  required  in  the 
arenas  of  live,  virtual,  and  constructive  simulation.  There  is  concern  for  the  common 
use  of  environmental  representations  in  a  wide  variety  of  national  and  international 
Defence  and  Commercial  systems.  The  SEDRIS  Interchange  Mechanism  will  eliminate 
data  stovepipes  by  addressing  total  of  existing  and  anticipated  data  interchange 
requirements,  rather  than  their  lowest  common  denominator  intersection. 

6.1.1  SEDRIS  Technical  Components 

SEDRIS  developers  have  now  defined  all  the  technical  components  of  the  interchange 
mechanism: 

•  Common  Data  Representation  Model  (DRM)  -  removes  ambiguity  by  ensuring 
that  all  types  of  environmental  data  are  captured,  and  relationships  between  alternate 
representations  (eg.  feature  versus  geometry)  defined.  It  contains  object-oriented 
documentation,  in  two  versions,  enhanced  Rumbaugh  notation,  and  Unified 
Modeling  Language  (UML). 

•  Interface  Specification:  Documentation  defines  a  consistent  interface  between  a 
user's  (either  a  data  provider  or  a  data  consumer)  software  application  and  SEDRIS 
transmittals.  The  API  decouples  the  user's  application  from  the  transmittal's  data 
structures,  allowing  the  data  representation  model,  its  transmittal  mechanism- 
specific  data  structures,  and  the  user's  application  to  evolve  relatively  independently 
of  each  other.  Reference  implementations  of  both  a  read  and  write  API,  with 
supporting  libraries,  have  been  developed. 
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•  SEDRIS  Transmittal  Format  (STF)  provides  a  platform-independent  data 
interchange  format  for  SEDRIS  transmittals.  Its  file  format  defines  the  organisation  of 
a  persistent  SEDRIS  format.  Further  documentation  is  available  [28]. 

•  Environmental  Data  Coding  Specification  (EDCS)  provides  a  classification, 
attribute,  and  state  data-coding  standard.  This  allows  enumeration  to  be  separated 
from  both  the  data  model  and  the  data  dictionary  for  greater  flexibility  and 
enlargement.  EDCS  is  available  as  a  database  in  Access  form. 

•  Spatial  Reference  Model  (SRM)  defines  the  specification  of  co-ordinates, 
projections,  and  a  variety  of  spatial  reference  systems  as  used  in  SEDRIS  interchange. 

6.1.2  SEDRIS  Objectives  and  Deliverables 

SEDRIS  objectives  are: 

a)  to  articulate  and  capture  the  complete  set  of  data  elements  and  associated 
relationships  needed  to  fully  represent  the  physical  environment.; 

b)  to  support  the  full  range  of  simulation  applications  (eg.  computer-generated  forces; 
manned,  visual  and  sensor  systems)  across  all  environmental  domains  (terrain, 
ocean,  atmosphere  and  space);  and 

c)  to  provide  a  standard  interchange  mechanism  to  pre-distribute  environmental  data 
and  promote  database  reuse  and  interoperability  among  heterogeneous 
simulations. 

SEDRIS  deliverables  will  be: 

a)  Common  data  representation  model  and  associated  data  dictionary.  The  data 
model  will  remove  ambiguity  by  ensuring  that  all  types  of  environmental  data  are 
captured  and  relationships  between  alternate  representations  (eg.  feature  versus 
geometry)  defined. 

b)  Interface  Specification.  This  will  provide  a  consistent  interface  between  a  user's 
(either  a  data  provider  or  a  data  consumer)  software  application  and  SEDRIS 
transmittals.  The  API  decouples  the  user's  application  from  the  transmittal's  data 
structures,  allowing  the  SEDRIS  Data  Model,  its  transmittal  mechanism-specific 
data  structures,  and  the  user's  application  to  evolve  relatively  independently  of 
each  other. 

c)  SEDRIS  Transmittal  Format  (STF).  The  STF  provides  a  platform  independent  data 
interchange  format  for  SEDRIS  transmittals.  It  is  a  file  format  that  defines  the 
organisation  of  a  persistent  SEDRIS  format. 

d)  Data  Coding  Standard.  The  SEDRIS  Project  has  developed  a  classification,  attribute, 
and  state  data-coding  standard.  This  allows  enumeration  to  be  separated  from  the 
data  model  and  dictionary  for  greater  flexibility  and  extensibility. 

e)  Spatial  Reference  Model  (SRM).  The  SRM  fully  defines  the  specification  of  co¬ 
ordinates,  projections,  and  a  variety  of  spatial  reference  systems  as  used  in  SEDRIS 
interchange. 
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f)  Assodated  Tools  and  Utilities.  A  set  of  software  tools  and  utilities,  based  on  the 
SEDRIS  Interface  Specification,  has  been  developed  to  aid  in  viewing,  examining, 
and  validating  elements  of  a  SEDRIS  transmittal. 

6.1.3  Standardisation  of  SEDRIS 

SEDRIS  Technology  will  soon  begin  a  formal  review  process  towards  international 
standardisation.  This  process  will  include  all  technical  components  as  well  as  extend 
the  marketplace  for  SEDRIS  use.  SEDRIS  components  will  be  assessed  for  international 
use  within  Defence,  other  Government,  industry,  and  academic  applications.  Standards 
quality  documents  are  being  prepared,  as  is  documentation  supporting  SEDRIS  formal 
referencing  in  the  DoD  Joint  Technical  Architecture  and  in  procurement  directives.  The 
primary  standard  for  SEDRIS  core  technology  will  be  comprised  of  three  parts: 

•  Part  1:  SEDRIS  functional  specification 

•  Part  2:  SEDRIS  abstract  file  format 

•  Part  3:  SEDRIS  file  format  binary  encoding 

Part  1  will  specify  semantics  and  abstract  syntax  based  on  the  SEDRIS  data 
representation  model,  along  with  associated  data  types  and  elements  of  the  format.  It 
will  also  contain  a  functional  description  of  the  interface  specification  (both  the  Read 
API  and  the  Write  API). 

Part  2  will  contain  an  abstract  description  of  the  file  format  sufficient  to  lay  down  the 
ground  rules  for  encoding  this  file  format.  It  will  describe  how  the  file  format  is 
organised  and  how  the  functionality  and  data  model  described  in  part  1  is  to  be 
supported  in  a  file. 

Part  3  will  be  a  binary  encoding  of  the  abstract  description  contained  in  Part  2.  The 
rules  in  Part  2  and  the  definitions  in  Part  1  will  be  mapped  to  physical  values  and 
physical  data  types,  and  a  SEDRIS  Language  Bindings  multi-part  standard  initiated. 
The  Read  API  and  Write  API,  with  functional  descriptions  contained  in  Part  1  of  the 
core  standard,  need  to  be  mapped  to  real  programming  languages.  The  language 
mappings  that  have  been  assigned  are  Fortran  77,  Pascal,  Ada,  C,  and  Fortran  90. 

Language  bindings  are  required  to  map  the  abstract  data  types  and  function  interfaces 
defined  in  Part  1,  to  the  constructs  defined  by  the  International  Standards  Organization 
(ISO)  standard  for  the  programming  language  in  question.  The  C  language  mapping 
will  comprise  the  initial  work  effort.  Along  with  preparation  of  these  standards 
documents,  the  SEDRIS  Technical  Documentation  Set  is  being  completed.  All 
documents  will  be  available  to  SEDRIS  Users  from  the  SEDRIS  Project  at 
http:  /  /  www.sedris.org 
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6.2  Conceptual  Models  of  the  Mission  Space 

Simulation  developers  need  a  clear  picture  of  what  they  wish  to  represent  to  produce  a 
workable  model  or  simulation.  This  picture  will  be  multi-dimensional  and  must 
include  a  depiction  of  the  entities,  actions,  and  interactions.  When  fully  defined,  such  a 
resource  will  provide  an  evolvable  and  accessible  framework  of  tools  and  resources  for 
conceptual  analysis.  There  will  be  several  Conceptual  Models  of  the  Mission  Space 
(CMMS)  [29]  corresponding  to  broad  mission  areas  such  as  conventional  combat 
operations,  other  military  operations,  training,  acquisition  and  analysis.  The  mission 
space  structure,  tools  and  resources,  will  provide  an  overarching  framework.  They  will 
also  ensure  access  to  the  necessary  data  and  detail  to  permit  development  of  consistent, 
interoperable,  and  authoritative  representations  of  the  environment,  systems,  and 
human  behaviour  in  simulations. 

6.2.1  US  DoD  Implementation  of  CMMS 

As  part  of  the  US  DoD  M&S  Master  Plan  (MSMP),  the  US  DoD  must  develop  CMMS  to 
provide  a  basis  for  the  development  of  consistent  and  authoritative  simulation 
representations.  DMSO  is  leading  a  US  DoD-wide  effort  to  provide  an  integrated 
framework  and  toolset  for  developing  the  CMMS.  The  CMMS,  which  provides 
simulation-independent  warfighter  descriptions  of  real-world  processes,  entities, 
environments,  implementation  and  relationships,  is  composed  of  four  primary 
components: 

•  conceptual  models:  consistent  representations  of  real-world  military  operations, 

•  technical  framework:  standards  for  knowledge  creation 

•  common  repository:  a  database  management  system  (DBMS)  for  registration, 
storage,  management  and  release, 

•  library  toolset:  a  suite  of  tools  to  browse,  locate,  export  and  report  features  for 
accessing  and  using  mission  space  models  data 

CMMS  are  simulation  implementation-independent  functional  descriptions  of  the  real 
world  processes,  entities,  and  environment  associated  with  an  articulated  set  of 
missions.  In  particular,  they  provide: 

•  a  disciplined  procedure  by  which  the  simulation  developer  is  systematically 
informed  about  the  real  world  problem  to  be  synthesized; 

•  a  set  of  information  standards  the  simulation  subject  matter  expert  employs  to 
communicate  with,  and  obtain  feedback  from,  the  military  operations  subject 
matter  expert; 

•  the  real  world,  military  operations  basis  for  subsequent,  simulation-specific 
analysis,  design,  and  implementation,  and  eventually  verification,  validation,  and 
accreditation/  certification; 

•  a  singular  means  for  establishing  re-use  opportunities  in  the  eventual  simulation 
implementation  by  identifying  commonality  in  the  relevant  real  world  activities; 
and 
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•  a  library  of  re-usable  conceptual  models  for  simulation  development. 

6.2.2  CMMS  for  Australia 

To  promote  code  and  model  reuse,  and  to  be  interoperable  with  our  major  allies, 
Australia  will  also  need  to  define  CMMS  for  our  M&S  requirements,  hence  providing  a 
standardised  description  for  ADF  entities,  operational  environments  and  tactics  for 
each  service  need.  Such  an  effort  should  be  coordinated  through  the  ADSO  with 
appropriate  input  from  the  military  customer  and  DSTO.  Exact  implementation  of 
CMMS  for  Australia  (and  level  of  detail  required)  will  need  further  investigation,  and 
should  be  outlined  in  any  future  Defence  M&S  Master  Plan. 

6.3  Master  Environment  Library 

DMSO  has  developed  a  Master  Environment  library  (MEL),  which  is  an  on-line  Web- 
based  service  (http://mel.dmso.mil').  The  MEL  serves  as  a  repository  for  direct  and 
timely  access  to  models,  algorithms,  data,  and  products  for  all  environmental  domain 
areas  -  ocean,  terrain,  air  and  space. 

Natural  environment  data  reside  at  individual  resource  sites  worldwide.  These  data 
consist  of  static  features,  dynamic  features,  characteristics,  and  phenomena  of  the 
terrain,  ocean,  air,  and  space,  as  well  as  selected  permanent  and  semi-permanent 
geospatial  features  such  as  roads,  bridges,  buildings,  cities,  seaports,  and  airports. 

The  mission  of  MEL  is  to  provide  direct  and  timely  access  to  natural  environment 
information,  data,  and  products,  wherever  they  reside.  This  includes  non-geospatial 
data  such  as  models,  algorithms,  and  documents,  as  well  as  basic  environmental  data. 
MEL  is  currently  focused  on  US  DoD  modelling  and  simulation  users,  but  is  accessible 
to  other  DoD,  federal,  commercial,  and  academic  communities  as  well. 

For  the  warfighters,  MEL  supports  a  common  interoperable  view  of  the  battlespace  for 
mission  planning,  rehearsal,  and  execution.  MEL  supports  modelling  and  simulation 
for  training,  analysis,  and  acquisition,  thereby  helping  to  streamline  and  optimise  these 
processes. 

The  goal  of  MEL  is  to  become  the  "One-Stop  Environment  Shop",  where  users  can 
remotely  access  and  request  environmental  resources.  MEL  provides  a  digital  metadata 
database  plus  a  universal  interface  that  together  enable  a  user  to  browse  descriptive 
metadata  through  a  single  web  site. 

Any  requirment  for  an  Australian  equivalent  of  MEL  will  need  further  investigation, 
and  should  be  outlined  in  any  future  Defence  M&S  Master  Plan. 
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7.  Verification,  Validation  and  Accreditation 

The  Military  Operations  Research  Society  (MORS),  has  defined  the  key  elements  in 
establishing  a  model's  credibility  as  verification,  validation,  configuration  management 
and  accreditation,  namely: 

Verification  -  the  process  of  determining  that  a  model  implementation  accurately 
represents  the  developer's  conceptual  description  and  specifications.  Does  your  model 
do  what  you  think  it  does?  Does  it  do  the  'right  thing'? 

Validation  -  the  process  of  determining  the  degree  to  which  a  model  is  an  accurate 
representation  of  the  real  world  from  the  perspective  of  the  intended  uses  of  the  model. 
Just  how  good  is  the  model?  Does  it  do  the  things  right? 

Configuration  Management  -  the  application  of  technical  and  administrative 
oversight  and  control  over  the  model.  Which  version  of  the  model  you  have? 

Accreditation  -  an  official  determination  that  a  model  is  acceptable  for  the  specific 
purpose.  Is  the  model  good  enough  for  the  application  for  which  you  want  to  use  it? 

These  definitions  are  now  widely  accepted  in  the  M&S  community.  A  full  step-by-step 
guide  to  implementing  W&A  is  available  from  the  US  DoD,  Joint  Accreditation 
Support  Activity  [30]. 

7.1  VV&A  Descriptions 

Verification  amounts  to  an  inspection  of  the  M&S  system  and  its  documentation  to 
determine  if  a  given  set  of  requirements  (those  from  either  the  original  development  or 
some  using  activity's)  are  captured  correctly  throughout  the  design,  implementation, 
test  and  documentation.  In  addition  to  testing  for  functional  or  standards  requirements 
it  is  necessary  to  ensure  traceability,  so  that  all  functions  are  captured  correctly 
(according  to  specifications). 

A  Requirements  Traceability  Matrix  (RTM)  is  often  used  in  system  development  to 
record  (in  a  relational  database)  where  each  requirement  is  satisfied  in  documentation, 
in  code  or  hardware,  in  the  test  plan/ procedures.  Wherever  an  RTM  has  been 
maintained,  verification  is  greatly  simplified.  Verification,  to  be  affordable  and 
effective,  should  be  performed  on  a  priority  basis. 

Validation  comprises  examination  both  of  the  underlying  algorithms,  structure,  data, 
limitations,  and  assumptions;  and  of  their  suitability  for  a  given  use.  These  parameters 
should  be  specified  in  a  "conceptual  model".  Once  verified  and  validated,  the  model  or 
simulation  can  be  accredited  for  particular  use. 
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7.2  Verification  and  Validation 

Verification  and  Validation  can  be  considered  as  an  integrated  process  where  the 
results  of  one  task  provide  the  basis  for  the  next.  There  are  also  several  decision  points 
that  remind  the  verification  or  validation  practitioner  to  gather  existing  data  or  to 
check  the  task  list  to  ensure  that  only  necessary  tasks  are  undertaken. 

Verification  starts  with  a  list  of  prioritised  verification  requirements.  Existing 
verification  reports  and  data  are  checked  to  determine  which  requirements  are  satisfied 
or  which  selected  verification  tasks  can  be  satisfied.  Those  requirements  that  are 
satisfied  are  documented  in  an  appropriate  report  as  defined  by  the  accreditation 
documentation  requirements. 

Validation  begins  with  a  set  of  prioritised  validation  requirements,  stated  in  terms  of  die 
functions  within  a  model  that  need  to  be  validated  and  the  types  of  information  needed 
about  each.  Face  validation  is  the  lowest  level  of  validation  in  the  set  of  techniques,  and 
is  generally  sufficient  to  impart  a  moderate  level  of  credibility  to  a  model.  The  existing 
validation  reports  should  provide  sufficient  information  to  satisfy  any  or  all  of  the 
remaining  requirements.  If  not,  some  detailed  validation  will  be  required.  The  least 
costly  means  of  doing  results  validation  is  to  use  existing  data.  However,  if  not 
sufficient,  data  must  be  collected  from  test  programs. 

Once  source  data  to  perform  results  validation  is  available,  the  process  for  validating 
the  model  or  function  begins  with  the  preparation  of  a  validation  analysis  plan.  The 
input  data  and  any  adjustable  parameters  within  the  model  should  be  made  to 
correspond  to  the  values  that  represent  the  system  tested  and  the  environment  in 
which  it  is  tested.  The  model  is  then  run,  and  outputs  can  be  compared  to  the  same 
parameters  measured  during  the  test.  The  results  of  the  comparison  will  be  evaluated 
to  determine  if  the  model  accurately  represents  this  particular  real  world  evolution.  If 
not,  the  reason  for  the  difference,  either  model  or  source  data,  must  be  determined. 

Code  verification  involves  rigorous  desk  checking  and  software  testing  of  the  model 
code  to  determine  whether  the  equations  and  algorithms  specified  by  the  design 
documentation  are  correctly  implemented.  It  also  identifies  coding  errors,  assesses 
their  impact  on  model  predictions,  and  suggests  appropriate  modifications.  Detailed 
verification  gives  the  user  confidence  that  the  model  is  error  free  from  a  coding 
perspective,  and  that  all  the  model  assumptions  and  limitations  inherent  in  the 
algorithms  and  equations  have  been  identified.  A  fully  verified  model  also  eliminates 
the  likelihood  that  poor  comparison  with  test  data  in  validation  will  be  the  result  of 
unidentified  coding  errors. 

Detailed  validation  consists  of  gathering  real  world  data  for  comparison  with  model 
outputs  to  determine  if  the  results  are  adequate  for  the  application.  Real  world  data  are 
normally  collected  through  system  characterisation  tests  in  laboratories  or  from  system 
tests  at  test  ranges.  Significant  savings  can  be  realised  if  data  are  collected  from 
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ongoing  service  training  operations  and  system  testing,  instead  of  designing  specific 
tests  for  model  validation.  Leveraging  ongoing  test  programs  is  an  inherent  part  of  the 
recommended  V&V  process. 

Detailed  validation  gives  the  user  confidence  that  the  accuracy  of  model  predictions  is 
known  for  specific  input  conditions.  From  this  it  can  be  determined  whether  or  not  this 
level  of  fidelity  is  adequate  for  the  intended  application.  Again,  a  clear  definition  of 
fidelity  requirements  for  the  intended  application  is  necessary  before  validation  results 
can  be  put  into  context. 

7.3  Accreditation 

Accreditation  requirements  are  derived  from  three  sources;  the  level  of  credibility 
needed,  any  unique  requirements  specified  by  the  accreditation  authority,  and 
requirements  specified  by  Defence  and  Service  policies.  The  level  of  credibility  needed 
for  a  given  application  depends  on  two  factors,  the  risk  or  benefit  associated  with  the 
final  problem  outcome  or  decision,  and  whether  there  is  any  corroborating  information 
that  will  be  used  in  conjunction  with  the  model  outputs  to  reach  a  decision  or  influence 
the  outcome. 

Accreditation  authorities  tend  to  treat  V&V  in  terms  of  model  strengths  and 
weaknesses.  The  first  concern  is  what  a  model  can  do  in  broad  terms  and  its  prior  use 
in  any  similar  applications.  The  details  of  how  the  model  functions  and  the  manner  in 
which  it  represents  the  real  world  are  then  considered,  and  finally,  detailed  V&V  is 
used  to  build  confidence  that  the  code  is  error  free  and  compares  favourably  with  real 
world  data  at  the  detailed  level. 

The  accreditation  assessment  begins  with  the  comparison  of  the  modelling 
requirements  with  the  data  on  the  model's  capabilities  and  attributes.  If  no  deficiencies 
are  identified,  the  recommendations  and  rationale  for  accreditation  are  easily 
developed  and  documented.  If  some  deficiencies  are  identified,  an  impact  analysis  is 
required  for  each  deficiency. 

The  accreditation  authority  will  consider  areas  of  weakness  within  the  model  or 
simulation,  how  model  outputs  are  affected  by  suspect  model  inputs,  and  how  those 
outputs  will  most  likely  impact  the  expected  application  decisions  or  outcomes.  No 
model  is  perfect;  the  accreditation  authority's  primary  question  will  be  to  determine 
the  risks  if  the  recommended  model  is  used.  Any  actions  or  steps  that  can  be  taken  to 
mitigate  the  impact  of  model  weakness  should  also  be  examined.  Manual  adjustments 
of  input  or  output  values  or  changes  to  functional  parameters  within  the  model  may 
often  compensate  for  model  deficiencies  and  preserve  the  ability  to  use  a  particular 
model  that  has  some  deficiencies.  Other  work-arounds  may  include  limiting  the 
model's  use  to  certain  scenarios  where  the  outputs  are  known  to  be  acceptable. 
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The  last  element  of  the  accreditation  process  is  documenting  the  recommendations  and 
rationale.  The  purpose  of  the  documentation,  which  consists  of  the  accreditation  plan, 
the  accreditation  report,  and  possibly  the  V&V  reports,  is  to  record  the  final  decision  in 
a  clear  and  understandable  manner,  with  analytical  results  written  so  that  the  logic  is 
clearly  evident.  The  documents  should  contain  a  complete  explanation  of  the  analysis 
that  supports  the  development  of  the  modelling  requirements.  Also  the  results  of  the 
accreditation  reviews  must  be  clearly  articulated  along  with  the  rationale  for  any 
judgements  and  the  qualifications  of  the  personnel  making  these  judgements. 

The  final  step  in  the  accreditation  process  is  obtaining  the  approval  of  the  accreditation 
authority,  namely  the  individual  who  is  responsible  and  accountable  for  decisions  or 
actions  based  upon  the  specific  M&S  usage.  To  make  a  sound  accreditation  decision, 
the  accreditation  official  must  understand  the  "big  picture"  along  with  application 
goals,  constraints,  and  decision  thresholds.  This  official  should  be  aware  of  why  M&S 
is  being  used,  other  analytic  or  non-M&S  sources  of  decision  support  data,  the 
scenarios  and  concepts  that  are  being  used  in  the  M&S  analysis,  and  the  top  level 
guidance  concerning  M&S  management  and  usage. 

7.4  Other  W& A  Issues 

7.4.1  Cost  of  W&A 

The  cost  of  V&V  should  be  commensurate  with  the  importance  of  the  M&S  in  decisions 
that  ultimately  affect  the  'warfighter.'  If  it  is  used  purely  for  demonstration  purposes, 
there  may  be  little  need  to  conduct  V&V.  The  costs  of  V&V  should  be  borne  by  the 
user,  but  should  be  limited  to  those  costs  uniquely  attributable  to  the  use  for  which 
accreditation  is  sought,  such  as  requirements  review,  V&V  planning,  assistance  with  or 
development  of  a  good  'validation  test'  and  the  cost  of  developing  the  V&V  reports. 

7.4.2  Data  W&C 

A  model's  input  data  is  just  as  important  as  the  model  itself  if  realistic  answers  are  to 
be  expected.  For  many  complex  models,  the  model  frequently  IS  the  data.  Data  W&C 
is,  therefore,  an  essential  part  of  the  V&V  process.  In  the  context  of  W&C,  we  can 
make  the  following  definitions: 

•  Verification:  Ensures  that  input  data  sources  and  collection  conditions  and 
limitations  are  identified,  and  that  input  data  usage  in  the  model  is  defined. 

•  Validation:  Ensures  that  input  data  and  constants  are  consistent  with  the  best  or 
accepted  estimates. 

•  Certification:  Provides  formal  approval  of  the  validity  and  pedigree  of  a  data  set 
for  use  for  a  specific  purpose. 

In  most  cases  the  input  data  required  varies  according  to  the  application.  The  primary 
objective  for  data  certification  is  to  ensure  that  the  data  be  officially  recognised  as 
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consistent  with  the  requirements  of  the  application.  Data  W&C  gives  the  user 
confidence  that  the  data  used  in  the  model  have  been  obtained  from  credible  sources, 
are  consistently  used  throughout  the  model,  and  meet  the  requirements  of  the 
particular  application. 

7.5  VV&A  for  Networked  Simulations 

For  networked  simulations,  we  are  not  only  concerned  about  the  individual  W&A  of 
the  component  models,  as  discussed  in  the  previous  sections,  but  also  in  the  correct 
implementation  of  the  DIS  PDUs  (when  using  DIS)  or  the  correct  implementation  of 
HLA. 

7.5.1  Definitions  of  Interoperability 

There  are  different  levels  of  DIS  compliance,  compatability,  interoperability  and  fair 
fight,  which  have  the  following  definitions: 

DIS  Compliant:  A  simulation/  simulator  is  DIS  compliant  if  it  can  send  and  receive 
PDUs  in  accordance  with  IEEE  1278.  A  specific  statement  must  be  made  regarding  each 
PDU. 

DIS  Compatible:  Two  or  more  simulations/  simulators  are  DIS  compatible  if  they  are 
DIS  compliant  and  their  models  and  data  send  and  interpret  PDUs  to  support  the 
realisation  of  a  common  operational  environment  among  the  systems  (coherent  in  time 
and  space). 

DIS  Interoperable:  Two  or  more  simulations/ simulators  are  DIS  interoperable  for  a 
given  exercise  when  their  performance  characteristics  support  a  fair  fight  to  the  fidelity 
required  for  the  exercise. 

Fair  Fight:  Two  or  more  simulations/ simulators  can  be  considered  to  have  a  fair  fight 
when  differences  in  the  simulation's  performance  characteristics  have  less  effect  on  the 
results  than  user  actions. 

7.5.2  DIS  Test  Suite 

For  DIS,  which  is  the  preferred  networking  architecture  of  Navy's  SEA  1412  project,  a 
suite  of  DIS  Test  tools  have  been  developed  by  the  US  Army's  Simulation  and  Training 
Command  (STRICOM)  [31].  The  DIS  Test  Suite  (DTS)  was  developed  to  test  DIS 
compliance  of  simulations  and  simulators  prior  to  participation  in  DIS  exercises,  in  an 
internationally  accredited  automated  environment.  The  system  has  been  used  for 
testing  simulators  participating  in  the  International/ Industry  Training  Systems 
Education  Conferences. 
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The  DTS  is  a  software  package  that  runs  on  SGI  or  SUN  workstations  to  enable  the 
testing  of  specified  PDUs.  The  DTS  does  not  test  the  fidelity  of  the  model  used  in  the 
Application  Under  Test  (AUT);  rather  it  tests  the  ability  of  the  AUT  to  send,  receive 
and  interpret  properly  formatted  PDUs. 

Once  the  DTS  software  is  operating,  the  AUT  is  activated.  The  domain  of  the  AUT  is 
specified  as  the  tests  depend  on  the  type  of  vehicle  or  platform  being  simulated.  The 
DTS  assumes  that  the  simulator  represents  a  vehicle  or  platform  such  as  an  aircraft  or 
ship,  and  hence  the  applicability  of  the  DTS  to  simulators  that  do  not  represent 
platforms  is  limited.  The  AUT  is  then  moved  to  a  specific  part  of  a  defined  data  base, 
which  must  be  used  as  the  geographic  location  for  the  simulation.  The  DTS  then 
generates  PDUs  which  the  AUT  must  receive  and  interpret.  Only  PDUs  exported  by 
the  DTS  are  used  in  the  test.  The  AUT  display,  assumed  to  be  an  "out  of  the  window" 
visual  display,  is  then  examined,  visual  inspection  of  the  simulator's  representation  of 
some  aspect  of  the  exported  entity's  appearance  or  behaviour  made,  and  a  decision 
made  on  whether  the  specified  conditions  have  been  met.  This  inspection  is  qualitative 
in  nature. 

The  DTS  does  not  examine  the  numerical  values  of  fields  within  the  PDUs,  nor  does  it 
check  whether  the  simulation  correctly  passes  its  state  values  (position,  velocity, 
orientation,  etc.)  in  these  fields.  Use  of  the  VR-Link  toolkit  will  always  generate 
correctly  formatted  PDUs  given  the  numerical  values  obtained  from  the  simulation. 
Testing  whether  these  values  are  correct  is  not  part  of  the  DTS  as  such;  they  are  only 
tested  indirectly,  and  in  a  qualitative  manner,  from  the  knowledge  that  if  they  were 
wrong  it  would  not  be  possible  to  view  the  DTS  exported  entities  in  a  realistic  manner. 

Testing  and  accrediting  simulators  for  DIS  compliance  is  an  important  stage  of  the 
development  of  DIS  within  Australia.  For  projects  such  as  SEA  1412,  which  will  utilise 
DIS  as  the  networking  architecture,  it  will  be  necessary  for  an  accreditation  authority  to 
be  recognised  to  ensure  full  DIS  compliance.  AOD  is  currently  negotiating  with 
STRICOM  to  produce  a  DTS  that  can  test  at  the  DIS  2.1.4  standards. 


8.  Australian  M&S  Future  Strategy 


Modelling  and  simulation  techniques  are  being  used  increasingly  within  Defence.  A 
1998  report  by  the  Australian  National  Audit  Office  [32]  stated  that  Defence  would 
invest  over  $A1.1  billion  in  simulation  over  the  following  five  years.  Recognising  the 
need  for  overall  policy  direction  and  co-ordination  across  the  many  application  areas 
for  simulation  in  Defence,  the  Defence  Simulation  Coordination  Group  (DSCG) 
developed  a  draft  Simulation  Policy  and  Master  Plan  [33  -  37]  during  the  period  1996- 
98. 
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Following  direction  from  the  Defence  Capability  Forum,  a  Defence  Strategic  Plan  [38] 
was  then  produced,  based  on  the  ideas  outlined  in  the  draft  Simulation  Master  Plan.  In 
July  1999,  the  Defence  Capability  Forum  decided  to  establish  the  Australian  Defence 
Simulation  Office  (ADSO),  hence  implementing  one  of  the  key  recommendations  of 
both  the  draft  Simulation  Master  Plan  and  the  Defence  Strategic  Plan. 

8.1  Australian  Defence  Simulation  Office  (ADSO) 

ADSO,  headed  by  the  Director-General  Simulation  (DGSIM),  is  a  Branch  within  the 
Australian  Defence  Headquarters  (ADHQ)  Capability  Staff  which  reports  directly  to 
the  Chief  Knowledge  Officer.  ADSO's  mission  is  to  promote  the  most  effective  and 
efficient  exploitation  of  computer-based  modelling  and  simulation  capabilities  for  the 
defence  of  Australia  and  its  interests,  through: 

a)  policy  direction  -  to  advance  the  use  of  computer-based  modelling  and  simulation 
(M&S)  in  Defence; 

b)  co-ordination  -  to  enable  enhanced  outcomes  through  securing  synergy  and 
resource  benefits  in  computer-based  M&S  activities  across  Defence;  and 

c)  collaboration  -  to  foster  productive  defence  partnerships  in  computer-based  M&S 
with  industry,  academia  and  overseas  organisations. 

Customers  for  ADSO  outputs  comprise  Defence  stakeholders  including:  Navy,  Army, 
Air  Force,  Joint  Commands,  Strategy,  Intelligence,  Materiel,  Capability  Staff,  JET/PE, 
and  DSTO.  Stakeholders  external  to  Defence  include  representatives  from  industry, 
academia  and  overseas  partners. 

ADSO  will  provide  for  the  needs  of  its  stakeholders  through: 

•  formulation  of  appropriate  guidelines  for  the  development,  acquisition  and  use  of 
computer-based  modelling  and  simulation  systems  in  Defence; 

•  securing  benefits  for  the  ADF  from  the  co-ordination  of  computer-based  modelling 
and  simulation  activities  in  Defence; 

•  promoting  interoperability  within  Defence  and  with  overseas  partners  to  facilitate 
mutually  beneficial  collaboration; 

•  fostering  participation  by  Australian  industry  and  academia  in  Defence  computer- 
based  modelling  and  simulation  activities  to  achieve  the  highest  leverage  for  the 
Defence  effort;  and 

•  encouraging  growth  within  the  Defence  Organisation  of  the  skills  needed  in 
personnel  who  can  then  take  full  advantage  of  the  opportunities  offered  by 
computer-based  modelling  and  simulation  for  the  enhancement  of  ADF  capability. 

8.2  Defence  M&S  -  The  Way  Ahead 

A  key  feature  of  ADSO's  Policy  Direction  agenda  [39]  is  to  develop  and  implement  a 
management  structure  for  the  formulation  of  Defence-wide  computer-based  M&S 
policy  that  satisfies  Australia's  defence  needs.  At  the  same  time,  ADSO  will  be  working 
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to  increase  awareness  and  understanding  across  Defence  of  the  potential,  opportunities 
and  limitations  of  M&S  by  leading,  encouraging,  contributing  to  and  co-ordinating  a 
program  of  focussed  lecture  tours,  papers  and  demonstrations  as  appropriate. 

ADSO  will  play  an  important  role  in  promoting  interoperability,  where  desired,  within 
and  among  Defence  Programs  and  with  allies  and  partners  via  the  adoption  of 
international  standards  for  the  networking  of  distributed  simulations.  This  was  one  of 
the  cornerstones  of  the  draft  Simulation  Master  Plan,  and  has  been  reported  widely 
[33-  37].  An  investigation  will  be  made  into  the  potential  for  a  Defence-wide  M&S 
infrastructure  that  could  realise  benefits  deriving  from  joint,  combined  and  coalition 
interoperability. 

ADSO  plans  to  establish  and  lead  a  Defence  Simulation  Advisory  Forum  (DSAF) 
chaired  by  the  Director-General  Simulation  (DGSIM)  and  drawing  on  representatives 
of  its  major  stakeholders'  base,  to  address  Defence-wide  M&S  matters.  Heading  the  list 
of  issues  for  DSAF  are  promulgating  guidelines  for  the  development,  acquisition  and 
use  of  M&S  systems  in  Defence,  and  specifying  ways  of  benefiting  from  the  co¬ 
ordination  of  M&S  activities.  DSAF  will  also  look  into  achieving  interoperability  for 
collaboration  both  internally  and  with  overseas  partners,  securing  high  leverage 
participation  by  industry  and  academia,  and  instituting  appropriate  training  and  career 
development  for  M&S  personnel. 

Opportunities  for  synergy  across  a  wide  spectrum  of  M&S  applications,  from  stand¬ 
alone  simulations  to  networks  of  interacting  distributed  simulations  running  in  a 
common  scenario,  will  be  investigated  by  ADSO.  ADSO  proposes  to  define  and 
promote  standards  where  appropriate  and  possible  for  a  common  technical  framework 
(architecture,  conceptual  models,  data  standards,  networking  standards)  and  common 
support  services  (networks,  databases,  supporting  tools)  to  achieve  a  cost-effective 
level  of  interoperability. 

ADSO  plans  to  determine  feasibility  and  progress  development  of  standards  and 
procedures  for  validation,  verification  and  accreditation  of  computer-based  models 
and  simulations.  It  will  also  plan  for  the  development  of  a  Joint  Synthetic  Environment 
(JSE)  concept  demonstrator,  through  linking  several  simulation  systems  within  a 
common  technical  framework  and  support  services. 

ADSO  proposes  to  sponsor  DSTO  work  to  advance  Defence's  R&D  activities  designed 
to  maintain  knowledge  about,  and  participation  in,  the  development  and  applications 
of  emerging  M&S  technologies.  ADSO  will  therefore  monitor  and  contribute  to  efforts 
by  DSTO  to  maintain  and  strengthen  links  with  international  M&S  agencies,  and 
promote  collaboration  in  research,  development  and  information  exchange  with  other 
countries  through  bilateral  and  multilateral  arrangements. 
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An  important  early  venture  will  be  the  management  of  a  contacted  feasibility  study 
with  industry  for  the  definition  of  a  Joint  Synthetic  Environment  capability  to  meet 
identified  Defence  stakeholder  needs. 

In  1997  [33]  it  was  envisaged  that  it  would  take  around  ten  years  before  the  M&S 
capabilities  listed  above,  including  the  use  of  a  Joint  Synthetic  Environment  for  a 
multitude  of  uses  such  as  training,  analysis  and  acquisition,  would  be  fully  utilised  in  a 
seamless  manner  by  the  Australian  Defence  Department.  The  establishment  of  a  Joint 
Synthetic  Environment  would  be  the  first  step,  and  would  be  best  utilised  initially  in  a 
military  training  role.  This  would  then  allow  the  opportunity  to  validate  the  system 
(with  a  comparison  able  to  be  made  with  the  results  from  live  training)  before  it  was 
extended  for  use  in  analysis  and  acquisition. 


9.  Simulation  Interoperability  Standards  Organisation 

(SISO) 


The  Simulation  Interoperability  Standards  Organisation  (SISO)  is  an  organisation 
dedicated  to  the  promotion  of  modelling  and  simulation  interoperability  and  reuse  for 
the  benefit  of  diverse  M&S  communities,  including  developers,  procurers,  and  users, 
world-wide.  SISO  promotes  itself  as  the  world's  foremost  organisation  for  anyone, 
anywhere,  interested  in  the  interoperability  and  reuse  of  M&S  resources.  SISO 
workshops  and  meetings  have  become  the  favoured  meeting  places  for  M&S 
professionals  to  share  experiences  and  knowledge.  Detailed  explanations  of  the 
organisation,  standards  development  procedures,  and  conference  activities,  can  be 
found  within  the  "SISO  Policies  and  Procedures"  document  [40]. 

SISO's  mission  is:  To  provide  an  open  forum  that  promotes  the  interoperability  and  reuse  of 
models  and  simulations  through  the  exchange  of  ideas,  the  examination  of  technologies,  and  the 
development  of  standards.  This  mission  statement  reflects  the  multiple  dimensions  of 
SISO.  A  climate  of  openness,  innovation  and  technical  excellence  is  promoted.  Meeting 
on  this  common  ground,  the  membership  share  ideas,  debate  issues,  reach  consensus 
agreements,  and  develop  standards.  This  can  only  benefit  simulation  interoperability 
and  reuse. 

To  fulfil  the  precepts  laid  out  in  SISO's  vision  and  mission  statements  and  to  build 
upon  the  operating  principles  embraced,  SISO  will  focus  on  four  areas: 

•  broadened  participation; 

•  standards  development; 

•  workshops  and  conferences;  and 

•  independence. 


36 


DST  O-GD-0255 


9.1  Broadened  Participation 

The  M&S  community  (especially  in  the  USA)  is  fragmented  by  numerous  barriers  that 
breed  "stovepipe"  solutions  diametrically  opposed  to  interoperability  and  reuse  of 
M&S  resources.  Many  communities  do  not  work  together  toward  common  solutions. 
Furthermore,  those  communities  that  have  traditionally  worked  toward  M&S 
interoperability  have  been  dominated  by  the  US  DoD,  whose  interests  are  not  inclusive 
of  all  M&S  domains. 

SISO  is  in  the  preliminary  stages  of  breaking  down  traditional  barriers  and  bringing 
together  various  communities  to  develop  common  solutions  for  shared  problems.  To 
fully  satisfy  the  SISO  vision,  effort  is  being  made  to  broaden  the  representation  of 
communities  not  previously  involved.  SISO  is  also  keen  to  ensure  a  better  balance  of 
participation  from  all  communities  so  the  process  will  not  be  dominated  by  any  one 
facet  of  the  M&S  community. 

An  active  outreach  program  is  essential.  SISO  aims  to  establish  its  role  by  educating  the 
M&S  community  on  the  value  of  standards  that  promote  interoperability  and  reuse. 
SISO  actively  persuades  members  of  the  M&S  community  to  become  further  involved. 
Examples  of  areas  SISO  aims  to  fully  embrace  are: 

•  non-DoD  government  activities; 

•  academia; 

•  medical  profession; 

•  Virtual  Reality  Modeling  Language  (VRML)  community; 

•  entertainment  and  gaming  industry; 

•  commercial  transportation  industry; 

•  city  planners,  industrial  developers,  and  emergency  management;  and 

•  M&S  practitioners  using  live  systems,  legacy  models,  distributed  interactive 
simulations  (DIS),  and  aggregate  level  simulation  protocols  (ALSP)  simulations. 

This  list  is  incomplete.  For  SISO  to  grow  to  its  full  potential  and  achieve  significant 
advances  in  interoperability  and  reuse  of  M&S  resources,  participation  must  be  open  to 
the  entire  M&S  community. 

9.2  Standards  Development  Process 

The  development  of  meaningful  standards  is  a  critical  SISO  activity.  Such  standards 
are  the  greatest  contributors  toward  broad  solutions  for  interoperability  and  reuse.  To 
be  valuable,  standards  must  be  responsive  to  the  M&S  community's  needs,  and  be 
timely,  relevant  and  of  excellent  quality. 

To  ensure  the  most  efficient  standards  development  process  possible,  SISO  is  trying  to 
ensure  that  it  is  responsive  to  the  communities  it  serves,  developing  standards  that 
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satisfy  their  needs.  This  can  be  accomplished  both  within  the  workshop  structure,  and 
outside  the  structure,  with  the  industry,  government  and  academic  communities. 

To  be  valuable  to  the  user  communities,  these  products  must  be  delivered  in  a  timely 
manner.  In  the  fast-changing  field  of  interactive  simulation,  SISO  realises  it  must 
deliver  its  products  quickly  to  maximize  their  intended  benefits.  This  is  accomplished 
by  keeping  Standards  Development  Groups  small,  tightly  focussed,  and  well 
supported,  and  by  adhering  to  the  principles  of  openness  and  responsiveness. 

SISO  aims  to  deliver  products  that  are  top-quality  and  relevant  to  the  various  user 
communities.  If  SISO  standards  and  other  products  do  not  add  value  for  the  user,  then 
they  will  not  be  used.  Conversely,  if  the  products  are  of  value,  they  will  be  widely 
used,  satisfying  their  intended  purpose  of  enhancing  interoperability  and  reuse. 

9.3  Workshops  and  Conferences 

Historically  rooted  in  the  Distributed  Interactive  Simulation  (DIS)  Workshop,  the  scope 
of  the  Simulation  Interoperability  Workshop  (SIW)  has  now  expanded  to  encompass  a 
broader  range  of  simulation  issues  and  communities,  including  US  DoD  and  other 
government  and  non-government  applications.  Workshop  participants  include 
simulation  developers,  simulation  users,  and  operations  analysts,  from  various 
government,  industry,  and  academic  communities. 

The  SIW  focuses  on  issues  involving  distributed  interoperable  and  composable 
simulations,  reuseable  components,  and  on  the  development  of  a  common  process 
model  for  designing,  composing,  executing,  and  analyzing  the  results  of  simulations, 
as  articulated  in  the  US  DoD  High  Level  Architecture  for  Modeling  and  Simulation. 
The  various  Workshop  Fora  provide  opportunities  for  user  and  technical  communities 
to  meet,  share  ideas  and  experiences,  identify  ways  to  make  distributed  simulation 
more  effective  and  efficient,  and  support  the  development  of  appropriate 
interoperability  standards. 

The  Workshop  includes  tutorials,  papers  on  state-of-the-art  experiences,  identification 
and  discussion  of  interoperability  issues,  and  presentation  of  proposed  solutions.  As 
these  solutions  are  prototyped  and  demonstrated,  they  become  candidates  for  possible 
standards  within  relevant  simulation  communities. 

Upon  approval  by  the  SISO  Executive  Committee,  a  Standards  Development  Group  is 
formed,  drawn  primarily  from  the  Workshop  Forum/ Fora  proposing  the  standard. 
The  Standards  Development  Group  reports  regularly  to  the  relevant  Workshop 
Forum/ Fora  regarding  its  progress,  and  seeks  comments  and  feedback.  When  the 
proposed  standard  is  judged  ready  for  formal  balloting,  an  appropriate  balloting  group 
is  formed  in  accordance  with  the  rules  of  the  IEEE  Computer  Society  Standards 
Activity  Board. 
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SIW  Fora  provide  an  opportunity  for  members  of  the  Modeling  and  Simulation 
community  who  share  common  interests  and/ or  are  involved  in  similar  functions  in 
various  organizations  to  exchange  ideas,  information,  and  technology,  to  share  "lessons 
learned,"  and  to  identify  areas  where  common  standards  and  practices  will  improve 
simulation  interoperability  and  reuse.  A  description  of  each  of  the  Workshop  Fora  is 
included  at  Annex  A. 

SISO  aims  to  become  the  "crossroads"  of  the  M&S  community.  SISO  meetings  and 
workshops  should  be  the  natural  venue  to  share  lessons  learned,  discuss  innovative 
solutions,  and  plan  strategies  that  optimise  interoperability  and  reuse.  This  will  enable 
professionals  interested  in  interactive  simulation  to  enhance  the  interoperability  and 
reuse  of  M&S  resources. 

To  reach  its  full  potential,  SISO  must  accomplish  two  things: 

a)  The  semi-annual  SIWs  must  continuously  adapt  to  provide  relevant  fora  that  best 
meet  the  needs  of  the  participants;  and 

b)  SISO  must  work  with  other  professional  bodies  to  host  joint  ventures.  These 
additional  gatherings  must  focus  on  key  elements  of  interactive  simulation 
technology  and  its  application  to  various  technology  areas. 

9.4  Vision  for  SISO 

To  best  realise  the  stated  vision,  SISO  aims  to  stand  on  its  own  (independent  from  US 
DoD  funding).  It  aims  to  be  self-contained  and  able  to  conduct  its  business 
independently.  This  will  allow  SISO  to  work  to  the  best  interests  of  the  broad  M&S 
community.  The  M&S  community  is  perceived  by  SISO  to  be  fragmented  by  numerous 
barriers  that  breed  "stovepipe"  solutions  diametrically  opposed  to  interoperability  and 
re-use  of  M&S  resources.  Many  communities  do  not  work  together  toward  common 
solutions  at  all.  In  addition,  there  are  commercial  pressures  that  continue  to  drive 
fragmentation.  SISO  aims  to  break  down  traditional  barriers  and  bring  together  various 
communities  to  develop  common  solutions  for  shared  problems.  For  SISO  to  grow  to 
its  full  potential  and  achieve  significant  advances  in  interoperability  and  re-use  of  M&S 
resources,  participation  is  open  to  the  entire  worldwide  M&S  community. 


10.  International  Simulation  Advisory  Group 

10.1  Formation  of  ISAG 

Whilst  the  UK's  influence  increased  at  the  SISO  Workshops,  the  UK  Government  and 
industry  had  no  input  to  the  standardisation  process.  This  was  a  major  concern,  with 
the  UK  Government  (in  1995)  about  to  commit  £200-300m  for  at  least  one  training 
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simulation,  the  Combined  Arms  Tactical  Trainer  (CATT).  The  UK  Ministry  of  Defence 
(through  the  UK  Simulation  Interoperability  Working  Group)  approached  the  DIS 
Steering  Committee  (as  it  was  then  known),  to  seek  a  place  at  tire  table  for  the  UK.  The 
SISO  Chairman  (from  HQ  STRICOM  at  the  time),  suggested  that  instead  of  just  the  UK, 
other  European  nations  should  also  be  represented.  He  asked  the  UK  SIW  to  organise 
this. 

As  a  result,  an  embryonic  organisation  (European  Simulation  Interoperability  Working 
Group  (ESIWG))  was  established.  The  group  consisted  of  11  European  Nations  with  4 
Co-chairmen,  UK,  France,  Germany  and  The  Netherlands.  This  activity  was  unfunded 
and  tire  Co-chairmanship  format  was  agreed  in  order  that  one  or  more  Co-Chairmen 
could  attend  most  of  the  meetings.  It  also  avoided  international  sensitivities  over 
leadership.  The  ESIWG  was  given  a  place  for  the  last  two  years  of  the  old  DIS  Steering 
Committee,  who  were  very  keen  to  hear  about  major  Non-North  American  DIS  issues. 

In  1996  SISO  broke  away  from  DOD/DMSO  and  set  up  as  an  independent  standards 
body,  similar  to  the  US  IEEE.  Organising  committee  membership  was  dominated  by 
US  Internet  voting  procedures. 

By  the  time  SISO  was  launched,  ESIWG  had  grown  to  have  Points  of  Contact  (POCs)  in 
36  Nations  and  4  organisations  (Eurocontrol,  European  Space  Agency,  NATO  and 
Simulation  Computer  Society  (International)).  As  it  was  no  longer  solely  a  European 
organisation,  it  was  renamed  in  1997,  the  International  Simulation  Advisory  Group 
(ISAG). 

The  Swedish  Government  has  funded  a  web  site  [41]  and  is  financing  administrative 
support.  The  Co-chairmen  have  been  expanded  to  6,  with  Australia  and  Sweden  being 
added.  ISAG  conducts  its  main  annual  meeting  in  conjunction  with  the  International 
Training  and  Education  Conference  (ITEC),  usually  held  in  The  Hague,  The 
Netherlands  in  April. 

SISO  approved  a  formal  associate  recognition  once  ISAG  had  approved  a  Charter.  This 
occurred  at  the  3rd  ISAG  meeting  at  ITEC98.  SISO  has  now  formally  recognised  ISAG  as 
an  SISO  affiliated  organisation.  The  USA  has  joined  ISAG  and  DMSO  provides  the 
POC.  Recently  the  UK  Co-Chairman  of  ISAG  was  elected  to  a  place  on  the  SISO 
Executive  Committee. 

10.2  ISAG  Aims  and  Achievements 

ISAG  aims  to  raise  those  issues  causing  international  concern  with  the  most 
appropriate  SISO  committees.  It  does  not  replace  or  interfere  with  the  normal  flow  of 
Workshop  papers  or  the  activities  of  the  SISO  Committee  members,  but  is  responsible 
for  action  on  issues  such  as  the  release  of  the  RTI  software  to  all  practitioners  via  the 
Internet,  as  requested  during  1997.  ISAG  backing  helped  the  DMSO  Director  to  win  his 
case  for  release. 
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In  1999,  ISAG  requested  the  formation  of  a  SISO  Forum  be  at  which  DIS  IEEE-1278 
transition  issues  could  be  discussed,  to  simplify  the  transition  to  HLA.  This  issue  was 
raised  at  the  DMSO  Industry  Steering  Group  Industry  Briefing  Days  in  Washington, 
and  with  considerable  support  from  the  US  community,  the  Forum  is  now  in  place. 

In  the  future,  ISAG  can  be  useful  to  SISO  when  SISO  moves  towards  incorporating  the 
US  IEEE  standards  as  ISO  standards.  To  do  this,  SISO  will  need  to  ensure  that  all 
interested  Nations  make  the  same  request,  in  the  same  committee,  in  each  National 
Standards  Organisation.  ISAG  is  ideally  suited  to  co-ordinate  that  process.  There  are 
signs  that  for  commercial  reasons,  the  US  may  try  to  retain  the  simulation  standards  as 
US  IEEE  only.  At  first  sight  this  could  be  commercially  damaging  to  the  industries  of 
other  Nations  who  could  find  that  they  have  no  choice  but  to  buy,  and  recommend  to 
clients,  only  US  products  such  as  the  RTI.  The  ISO  route  is  being  followed  for  the 
SEDRIS  standards  and  the  sponsors  are  keen  to  involve  ISAG  when  the  time  comes  for 
co-ordination. 

The  ISAG  Charter  and  list  of  Nations  and  Organisations  associated  with  ISAG  is 
included  at  Appendix  B. 


11.  Discussion 


Advanced  Distributed  Simulation  technologies  are  gradually  being  introduced  into 
Australia.  Terms  and  acronyms  used  within  ADS  are  in  a  glossary  at  Annex  C.  Initially 
linkages  for  fielded  military  applications  (networked  simulators)  should  be  developed 
using  DIS,  since  FILA  is  still  a  relatively  immature  technology.  An  upgrade  path  for 
DIS  compatible  simulators  to  HLA  has  been  identified,  and  will  provide  sufficient 
compliance  with  HLA  for  interoperability  with  Australia's  main  allies.  HLA  for  DSTO 
research  projects  (such  as  Virtual  Ship)  is  supported,  but  a  DIS  to  HLA  transition  path 
is  favoured  for  in-service  simulators,  to  allow  flexibility. 

Like  most  Defence  Forces  worldwide,  the  ADF  is  examining  the  issue  of  which 
approach  to  adopt: 

•  the  DIS  Protocol  for  its  networked  simulation  infrastructure; 

•  HLA,  which  is  still  evolving;  or 

•  DIS  initially,  whilst  developing  a  coherent  migration  strategy  towards  HLA  for  die 
future. 

The  Air  Operations  Division  of  DSTO  has  experience  in  the  area  of  DIS  and  HLA  over 
a  number  of  years  [42].  Based  on  both  this  background,  and  extensive  discussions  with 
both  overseas  and  local  simulation  personnel,  the  authors  consider  it  to  be  premature 
to  recommend  mandating  HLA  for  the  ADO,  for  the  reasons  outlined  in  the  following 
sections. 
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11.1  IEEE  Standardisation 

The  format  and  content  of  the  data  contained  within  DIS  PDUs  has  been  standardised 
by  the  US  IEEE.  Therefore  any  DIS  compliant  simulators  will  be  able  to  interoperate 
using  one  of  the  following  three  IEEE  standards: 

a)  IEEE  1278-1993 

b)  IEEE  1278.1-1995 

c)  IEEE  1278.1a-1998 

In  contrast,  HLA  is  not  standardised  at  this  level  since  its  data  format  and  content  are 
not  pre-defined.  The  standardisation  of  the  HLA  methodology  is  underway  [12]  -  with 
three  draft  standards  (designated  by  the  P)  currently  having  been  formulated: 

a)  P1516  -  Framework  and  rules 

b)  P1516.1  -  Federate  interface  specification 

c)  P1516.2  -  Object  Model  Template 

Although  parts  of  HLA  are  going  through  the  IEEE  standardisation  process,  this  is  not 
complete  and  it  would  seem  premature  to  consider  mandating  a  technology  that  is  not 
yet  an  international  standard. 

Once  the  HLA  methodology  has  achieved  IEEE  standardisation,  it  will  be  necessary  to 
standardise  the  reference  FOMs  (such  as  the  RPR-FOM),  in  order  to  obtain  a  similar 
level  of  standardisation  (and  interoperability)  currently  achieved  by  DIS. 

11.2  Cost  and  Risk 

To  enable  interoperability,  existing  ADF  Projects  such  as  SEA  1412  and  Virtual  Air 
Environment  are  initially  using  DIS.  Adding  an  Advanced  Distributed  Simulation 
interface  (be  it  DIS  or  HLA)  to  an  in-service  training  simulator,  may  cost  of  the  order  of 
several  million  dollars.  At  a  DMSO-run  HLA  course  held  at  Salisbury  in  late  1999,  it 
was  mentioned  that  a  small  US  Navy  wargame  was  converted  to  HLA  at  a  cost  of 
roughly  $US1M. 

Mandating  HLA  would  raise  the  issue  of  what  FOM  is  to  be  developed  and  who  uses 
it.  Until  such  an  Australian  Defence  FOM  (also  compatible  with  Allies)  is  agreed  upon, 
HLA  cannot  viably  replace  DIS  for  training  simulators.  Changes  or  modifications  to  a 
FOM  will  also  be  expensive  to  implement.  In  addition,  tools  such  as  viewers  and 
loggers  will  also  need  to  be  individually  created. 

11.3  Interoperability  with  Allies 

The  major  US  Programs  are  still  using  DIS.  For  example,  the  USN's  $US750M  Battle 
Force  Tactical  Training  (BFTT)  project  currently  uses  DIS  and  will  migrate  to  HLA  over 
several  years.  To  maintain  interoperability,  the  RAN  cannot  (at  present)  contemplate 
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migration  to  HLA  (SEA  1412  Project)  until  the  USN  BFTT  project  has  defined  their 
FOM  and  migration  process.  The  UK  Combined  Arms  Tactical  Trainer  (CATT),  at  a 
project  cost  of  £300M,  will  also  use  DIS  (with  a  transition  to  HLA  over  many  years). 
The  US  Army's  Close  Combat  Tactical  Trainer  (CCTT)  will  evolve  from  DIS  to  HLA  in 
a  similar  fashion. 

A  workshop  was  held  recently  in  Australia  [43]  in  which  the  problems  experienced  in 
the  US  services  with  the  HLA  mandate  were  discussed  in  a  panel  forum. 

11.4  Interoperability  within  Australia 

To  achieve  HLA  compliance,  all  systems  must  decide  on  the  same  FOM  for 
interoperability.  This  invites  the  question  as  to  which  FOM  does  the  ADO  use?  -  one  or 
several  different  ones.  Should  the  ADO  develop  its  own  FOM,  or  use  ones  developed 
overseas?  In  order  for  networked  simulators  to  be  HLA  compliant,  all  systems  must 
use  the  same  FOM  for  interoperability.  A  multiplicity  of  FOMs  will  create  stove-piped 
simulation  systems,  the  antithesis  of  the  goal  of  interoperability  in  a  Joint  Synthetic 
Environment. 

AOD  staff  participated  in  the  balloting  process  for  the  RPR-FOM  [9],  which  provides  a 
transition  path  to  HLA  by  mapping  DIS  Protocol  Data  Units.  This  is  the  only  FOM 
being  promoted  by  the  Simulation  Interoperability  Standards  Organisation  (SISO). 

In  contrast  to  HLA,  DIS  provides  out  of  the  box  interoperability  -  all  DIS  compliant 
systems  can  talk  to  each  other.  Thus  if  SEA  1412  and  VAE  use  DIS  they  will 
automatically  be  able  to  interoperate  -  if  they  used  HLA  with  different,  incompatible, 
FOMs  this  would  be  impossible.  SEA  1412  and  VAE  Projects  need  to  be  able  to 
interoperate  with  each  other  and  also  other  systems  coming  on  line. 

11.5  Lack  of  COTS  Support 

DIS  has  many  Commercial  Off  The  Shelf  tools  since  the  data  are  standardised.  By 
definition,  HLA  data  being  exchanged  is  only  standard  for  a  specific  federation.  This 
means  that  standard  tools  such  as  viewers  and  loggers  will  need  to  be  developed 
separately  for  each  FOM. 

11.6  Recommendations 

For  military  simulators  (especially  those  to  be  used  primarily  for  training),  DIS  is 
recommended  as  the  current  networking  standard.  Such  simulators  require  the 
flexibility  to  interoperate  with  other  simulators,  but  it  may  not  be  known  in  advance  (at 
the  time  of  development  and  deployment)  with  which  other  simulators  they  might 
interoperate.  The  advantage  of  DIS  is  that  all  DIS-enabled  simulators  can  interoperate. 
With  HLA,  the  exact  data  transfer  mechanism,  the  FOM,  must  all  be  agreed  in  advance. 
It  is  necessary  to  know  with  which  simulators  you  wish  to  network.  If  HLA  is  deemed 
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to  be  absolutely  necessary  as  the  networking  architecture,  then  the  RPR-FOM  should 
be  specified. 

For  research  projects  and  simulations  used  for  analysis,  which  can  be  designed  to 
network  with  other  simulations  known  in  advance,  the  new  HLA  may  be  preferred. 
The  Virtual  Ship  Project  is  an  excellent  example  of  a  DSTO  research  project,  where  the 
use  of  HLA  is  ideal.  Since  the  interoperability  can  be  planned  ahead,  the  FOM  can  be 
tailor-made  to  suit  the  application. 

HLA  is  new  and  exciting  technology  that  will  ultimately  offer  many  advantages  over 
DIS.  It  is  an  excellent  research  area  for  DSTO,  with  its  long  tradition  of  M&S,  to 
investigate  in  the  laboratory  environment.  An  Australian  Defence  Organisation  FOM 
does  not  exist  and  should  not  be  developed  until  agreement  is  reached  on  likely  allied 
Nation  projects  with  which  Australia  wishes  to  interoperate  (eg  BFTT).  Therefore,  it  is 
highly  premature  to  mandate  its  use  for  the  ADO.  Mandating  HLA  would  compromise 
interoperability  between  ADF  in-service  (or  soon  to  be  in-service)  training  systems  and 
with  the  US  and  other  allies. 

The  authors  recommend  a  cautious  approach  to  the  introduction  of  HLA  into  the  ADO 
following  the  US  experience.  One  of  the  roles  of  ADSO  will  be  to  ensure  that,  through 
appropriate  Defence  Exchange  Agreements,  the  ADO  can  work  with  our  allies 
(particularly  the  US  and  UK)  to  ensure  that  ADF  in-service  training  systems  will 
migrate  to  HLA  while  retaining  interoperability. 

12.  Conclusions 


The  US  DMSO  has  initiated  a  comprehensive  range  of  programs  to  simplify  the 
development  of  M&S  within  their  military.  This  was  started  to  address  existing  deep- 
rooted  problems  within  their  community  for  development  of  M&S.  Various  programs 
were  commenced  to  address  interoperability,  data  standardisation,  terrain  database 
interchange,  common  conceptual  models  of  military  operations,  inter  alia.  Australia  can 
benefit  through  attendance  at  workshops  and  conferences  where  these  new  programs 
and  standards  are  being  developed. 

A  key  issue  is  the  gradual  introduction  of  Advanced  Distributed  Simulation 
technologies  into  Australia.  Both  the  ADF  and  DSTO  have  various  active  programs 
using  these  technologies.  Initially  linkages  will  be  developed  using  DIS,  since  HLA  is 
still  a  relatively  immature  technology.  An  upgrade  path  for  DIS  compatible  simulators 
to  HLA  has  been  identified  This  will  provide  sufficient  compliance  with  HLA  for 
interoperability  with  Australia's  main  allies. 
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14.  Glossary  of  Acronyms 


ADAC2s 

Air  Defence  and  Airspace  Command,  Control  and 
Communication  system 

ADF 

Australian  Defence  Force 

ADGE 

Air  Defence  Ground  Environment 

ADO 

Australian  Defence  Organisation 

ADS 

Advanced  Distributed  Simulation 

ADSO 

Australian  Defence  Simulation  Office 

AEW&C 

Airborne  Early  Warning  &  Control 

AOD 

Air  Operations  Division 

AOSC 

Air  Operations  Simulation  Centre 

API 

Application  Programmer's  Interface 

ARH 

Armed  Reconnaissance  Helicopter 

AUT 

Application  Under  Test 

BFTT 

Battle  Force  Tactical  Trainer 

C?I 

Command,  Control,  Communications,  and  Intelligence 

C4ISR 

Command,  Control,  Communications,  Computers, 
Intelligence,  Search  &  Reconaissance 

CATT 

Combined  Arms  Tactical  Trainer 

CCTT 

Close  Combat  Tactical  Trainer 

CGE 

Computer  Generated  Entity 

CGF 

Computer  Generated  Forces 

CMMS 

Conceptual  Models  of  the  Mission  Space 

COTS 

Commercial-Off-The-Shelf 

DDG 

Guided  Missile  Destroyer 

DIS 

Distributed  Interactive  Simulation 

DIU 

DIS  Interface  Unit 

DMSO 

Defense  Modeling  and  Simulation  Office  (US) 

DoD 

US  Department  of  Defense 

DSAC 

Defence  Simulation  Advisory  Council 

DSTO 

Defence  Science  &  Technology  Organisation 

DTS 

DIS  Test  Suite 

EDCS 

Environmental  Data  Coding  Specification 

EMPDU 

Emission  PDU 

ESIWG 

European  Simulation  Interoperability  Working  Group 

ESPDU 

Entity  State  PDU 

EXC3ITE) 

Experimental  C3I  Technology  Environment 

FFG 

Guided  Missile  Frigate 

FOM 

Federation  Object  Model 
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HiL 

Human-in-the-Loop 

HLA 

High  Level  Architecture 

HQADF 

Headquarters,  Australian  Defence  Force 

IEEE 

Institute  of  Electrical  and  Electronic  Engineers 

IO 

Information  Organisation 

ISAG 

International  Simulation  Advisory  Group 

ISDN 

Integrated  Services  Digital  Network 

ISO 

International  Standards  Organisation 

1ST 

Institute  of  Simulation  and  Training  (US) 

ITEC 

International  Training  and  Education  Conference 

JASA 

Joint  Accreditation  Support  Activity  (US  DoD) 

JORN 

Jindalee  Operational  Radar  Network 

JSE 

Joint  Synthetic  Environment 

LAN 

Local  Area  Network 

M&S 

Modelling  and  Simulation 

MEL 

Master  Environment  Library 

ModSAF 

Modular  Semi  Automated  Forces 

MORS 

Military  Operations  Research  Society 

MWTC 

Maritime  Warfare  Training  Centre 

OBTS 

On  Board  Training  Systems 

OMT 

Object  Model  Template 

PDU 

Protocol  Data  Unit 

RAAF 

Royal  Australian  Air  Force 

RAN 

Royal  Australian  Navy 

RPR-FOM 

Real  time  Platform  Reference  FOM 

RTI 

Run  Time  Infrastructure 

RTM 

Requirements  Traceability  Matrix 

SBA 

Simulation  Based  Acquisition 

SEDRIS 

Synthetic  Environment  Data  Representation  and 
Interchange  Specification 

SISO 

Simulation  Interoperability  Standards  Organisation 

SIW 

Simulation  Interoperability  Workshop 

SOM 

Simulation  Object  Model 

SRM 

Spatial  Reference  Model 

STF 

SEDRIS  Transmittal  Format 

STRICOM 

Simulation  Training  and  Instrumentation  COMmand 
(US  Army) 

TTCP 

The  Technical  Co-operation  Program 

UML 

Unified  Modeling  Language 

USN 

United  States  Navy 
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VAE 

Virtual  Air  Environment 

VRML 

Virtual  Reality  Modeling  Language 

VSAWG 

Virtual  Ship  Architecture  Working  Group 

VSEM 

Virtual  Ship  Execution  Manager 

W&A 

Verification,  Validation  and  Accreditation 

W&C 

Verification,  Validation  and  Certification 

WAN 

Wide  Area  Network 
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Appendix  A:  SISO  WORKSHOP  FORA 

The  following  sections  describe  the  SISO  workshops. 

A.l.  Analysis  Forum  (ANL) 

ANL  is  concerned  with  interoperability  issues  and  uses  of  distributed  models  and 
simulations  for  analysis.  ANL  encourages  the  education  of  the  analysis  community 
about  Advanced  Distributed  Simulation  (ADS)  and  of  the  developers  of  ADS  about 
analytic  requirements.  ANL  currently  focusses  on  process  developments  that  will 
identify  user  requirements.  Topics  of  interest  include: 

•  experiences  doing  pre-exercise,  rim-time,  or  post-exercise  analysis  in  ADS; 

•  the  role  of  the  analyst  in  the  HLA  FEDEP; 

•  processes  to  develop  requirements  for  analytic  federates  and  federations; 

•  identification  of  model  and  simulation  interoperability  issues  for  analysis; 

•  methods  to  address  experimental  design  that  incorporate  ADS  as  an  analytic  tool; 
and 

•  issues  for  analysis  in  Simulation  Based  Acquisition. 

A.2.  Research,  Development,  and  Engineering  Forum  (RDE) 

RDE  is  concerned  with  issues  and  uses  of  distributed  models  and  simulations  within 
the  Research,  Development  and  Engineering  domain.  RDE  currently  focusses  on 
interoperability  of  distributed  simulation  in  supporting  user  requirements.  Topics  of 
interest  include: 

•  experiences  in  creating,  implementing,  operating  or  delivering  simulations  for  RDE 
problems; 

•  processes  to  develop  interoperability  or  model  re-use  requirements  for  RDE 
federates  and  federations;  and 

•  processes,  procedures  or  methods  of  evaluating  fidelity  requirements  and  model 
credibility  for  experimentation. 

A.3.  Test  and  Evaluation  Forum  (TE) 

TE  is  concerned  with  uses  of  advanced  distributed  simulation  (ADS)  in  test  and 
evaluation  (T&E),  including  the  incorporation  of  live  entities  with  virtual  and 
constructive  simulations,  and  the  linking  of  historically  stand-alone  T&E  facilities  into 
distributed  simulations.  Currently,  topics  of  interest  are: 

•  experiences  using  ADS  to  support  T&E; 

•  experiences  linking  ADS  and  test  ranges;  and 

•  interoperability  testing. 
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A.4.  Training  Forum  (TRAINING) 


TRAINING  is  a  newly  created  forum,  through  the  merger  of  the  former  Small  Team 
Training  (STT)  and  Staff  Level  Training  (SLT)  fora,  that  promotes  discussion  of  issues 
involving  simulation  in  training.  TRAINING  is  concerned  with  the  planning, 
management,  requirements,  and  use  of  simulations  that  provide  individual,  sub-team, 
and  team  training  to  system  operators,  team  leaders,  and  tactical,  operational,  and 
strategic  decision  makers.  There  is  a  special  interest  in  the  User  perspective  (training 
organizations,  sponsoring  agencies,  and  those  being  trained)  in  all  simulation 
environments.  In  particular,  TRAINING  is  currently  addressing  the  following  areas: 

•  results  and/ or  lessons  learned  from  the  conduct  of  major  or  significant  training 
events; 

•  simulation  training  effectiveness  in  a  multi-echelon  environment; 

•  interoperability  between  simulations  and  C4I  systems  directly  in  support  of  staff 
level  training  environments; 

•  validity  and  interoperability  of  simulation  and  operational  databases  used  for 
distributed  training; 

•  common  requirements  across  diverse  simulation  programs  including  needs  for 
common  FOMs/SOMs; 

•  distributed  mission  training,  non-combatant  (Military  Operations  Other  than  War 
(MOOTW)),  training  exercises,  and  training  the  Digitized  Force;  and 

•  methodologies  for  mapping  of  fidelity  measures  to  training  requirements. 

A.5.  Specialty  Area  Tracks 

Specialty  Area  Fora  bring  together  specialists  from  different  communities  to  discuss 
interoperability  and  component  re-use  issues.  Because  the  interests  of  participants  may 
span  multiple  areas,  the  Specialty  Area  Fora  are  organized  into  Tracks  to  facilitate 
planning  and  scheduling. 

A.5.1  Run-Time  Infrastructure  and  Communications  Forum  (RTI&C) 

RTI&C  deals  with  the  technical  aspects  of  getting  simulations  to  interoperate.  Current 
topics  of  interest  to  this  forum  include: 

•  RTI  implementation  descriptions; 

•  RTI  performance  characteristics; 

•  new  and  developing  communications  methods  and  standards,  and  how  they  can  be 
applied; 

•  to  distributed  simulations  (eg.,  reliable  multi-cast,  active  networks); 

•  alternate  federation  compositions,  such  as  composable  federations; 

•  single  process  federations;  single  address  space  federations,  etc;  and 

•  implementations  of  Quality  of  Service  capabilities  in  an  RTI. 
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A.5.2  Live  Interaction  Forum  (LIVE)  (co-administered  by  C4ISR) 

The  Live  Interaction  Forum  provides  an  opportunity  for  those  interested  in  live 
simulations  to  exchange  information  and  share  experiences.  The  Forum  is  focused  on 
the  issues  associated  with  simulations  that  depend  upon  live  participants  and  the 
associated  simulation  instrumentation.  Included  areas  of  interest  are  architecture, 
protocol,  instrumentation,  simulation  management,  and  numerous  technical  issues  that 
effect  stand-alone  live  simulations,  as  well  as  the  integration  of  live  simulations  with 
virtual  and  constructive  simulations  for  training,  test  and  evaluation,  and  other 
applications. 

A  primary  purpose  of  the  forum  is  to  evaluate  evolving  standards  and  supporting 
documents  to  ensure  that  they  realistically  promote  interoperability  with  live 
simulations  and  accurately  represent  the  boundaries  of  normal  operational  parameters. 

Of  particular  interest  to  the  Forum  are  issues  concerning:  known  or  anticipated 
shortcomings  in  existing  or  planned  architectures  and  implementations  for 
interoperable  simulations,  technical  issues  associated  with  the  live  simulation  domain 
applications  and  lessons  learned  in  live  simulations  for  training  or  T&E. 

A.5.3  Synthetic  Natural  Environment  Forum  (SNE) 

SNE  addresses  issues  concerning  digital  representations  of  the  natural  environment, 
including  air,  space,  land,  and  water.  Relevant  topics  span  the  life  cycle  of  digital 
environmental  representations,  including  requirements  definition,  data  collection  and 
production,  integration  and  validation,  extension,  transmission,  tailoring,  sharing,  and 
maintenance. 

A.5.4  Sensor  Forum  (SENS) 

The  Sensor  Forum  (SENS)  is  an  interdisciplinary  SISO  forum  chartered  to  address  the 
integration  of  sensors  and  sensor  models  into  live,  virtual  and  constructive  simulations. 
SENS  goal  is  to  recommend  practices  and  standards  in  the  areas  of  representation, 
interoperability,  fidelity,  correlation  and  interchange  mechanisms  for  use  by  the 
simulation  community.  The  SENS  forum  focusses  on  end-to-end  systems,  including 
propagation  effects  and  modelling  of  sensor  and  emitter  systems.  Functional  systems 
of  interest  incorporate  mechanisms  such  as  navigation,  communication,  search, 
detection  and  tracking.  The  sensing  regimes  used  in  these  systems  include,  but  are  not 
limited  to,  acoustic,  electromagnetic  (radar,  RF  etc.),  electro-optical  (IR,  visible,  etc.), 
chemical,  nuclear  and  biological  characteristics. 

A.5.5  Federation  Development  Process  Forum  (PROC) 

PROC  is  focussed  on  the  process  of  federation  development  and  execution  through 
sharing  of  practical  federation  development  experiences  across  the  HLA  user 
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community,  facilitating  the  identification  of  new  and  different  approaches  to  federation 
development  activities,  and  supporting  the  long-term  evolution  of  a  generalized 
process  model  for  HLA  federations  (HLA  FEDEP).  Current  topics  of  interest  are: 

•  Federation  objectives  development; 

•  Federation  scenario  /  conceptual  model  development; 

•  Federation  design  approaches  /  techniques;  and 

•  Object  model  development. 

A.5.6  Exercise  Management  Forum  (EMF) 

The  Exercise  Management  Forum  provides  an  outlet  for  discussing  tools  that  automate 
the  evolving  Federation  Development  Process.  The  Exercise  Management  Forum 
Proposes  functionality  and  interface  standards  for  tools  in  areas,  such  as: 

•  Planning; 

•  Initialization; 

•  Monitoring; 

•  Runtime  Controls; 

•  Data  Collection; 

•  Data  Analysis; 

•  Visualization;  and 

•  After  Action  Review. 

A .5.7  Verification,  Validation  &  Accreditation  Forum  (WA) 

WA  is  focussed  on  methodologies,  procedures,  and  associated  techniques  that  may  be 
used  to  establish  credibility  of  federations.  The  forum  objectives  emphasise  quality  (eg. 
building  in  authoritative  representations  and  behaviors)  and  risk  management.  WA 
will  support  the  development  and  evolution  of  W&A  guidance  to  supplement  the 
federation  development/ application  lifecycle  process  model  documentation.  Present 
topics  of  interest  include: 

•  empirical  data  on  the  Fidelity  Conceptual  Framework  (see  FEX-ISG  page  on  the 
SISO  web  site); 

•  validation  of  human  behavior  representations; 

•  substantive  interoperability;  and 

•  lessons  learned  on  W&A  of  distributed  simulations,  with  emphasis  on  conceptual 
models  (particularly  comparisons  of  actual  conceptual  model  development 
experiences  to  the  conceptual  model  framework). 

A.5.8  Testing  Forum  (TEST) 

TEST  will  discuss  techniques,  tools,  drivers,  and  methodologies  for  testing  as  it  applies 
to  HLA,  SISO  Standards,  and  the  transition  of  legacy  simulations  to  SISO  standards. 
Issues  raised  in  this  forum  will  provide  guidance  for  the  development  of  testable 
standards. 
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Testing  areas  include,  but  are  not  limited  to: 
Compliance  Testing; 

Interoperability  Testing; 

System  Testing; 

Integration  Testing; 

Regression  Testing; 

Performance  Testing; 

Acceptance  Testing; 

Stress  Testing;  and 
Scenario/ Exercise  Testing. 


A.5.9  Command,  Control,  Communications,  Computers,  and  Intelligence 
Forum  (C4I) 

C4I  is  concerned  with  the  modeling  and  simulation  of  C4I  systems  in  constructive, 
virtual,  and  live  environments.  C4I  is  particularly  interested  in  the  results  and  "lessons 
learned"  of  specific  projects/  experiments,  as  well  as  overarching  conceptual  issues 
involving  the  interoperability  of  simulation  systems  in  the  following  areas: 

•  C4I  functionality,  both  individual  systems  and  overall  processes  and  cycles; 

•  interoperability  of  real  systems  and  simulation  systems,  and  associated  issues  such 
as: 

-  common  (shared)  data/  object  models  and  reference  architectures; 

-  Measures  of  Effectiveness  (MOEs)  for  C4I  systems,  and  instrumentation  of  real 

and  simulated  C4I  systems  to  extract  information  for  MOEs  and  validation; 

-  implications  of  HLA,  DoD  JTA,  DII  COE,  and  other  respective  standards; 

-  embedding  of  simulation  systems  with  real-world  C4I  systems;  and 

-  the  coupling  of  real  and  simulated  C4I  systems  with  real  and  simulated  sensor 

and  weapon  systems,  and  sensor  fusion  issues. 


A.5.10  Information  Operations  -Intelligence,  Surveillance  and 
Reconnaissance  Forum  (IO-ISR) 

IO-ISR  is  concerned  with  the  interoperability  of  simulations  that  represent  systems  and 
activities  in  the  following  areas: 

•  Information  Operations  (IO),  with  particular  emphasis  on  research  into: 

related  human  behavioural  and  command  decision  process  modelling; 
supporting  taxonomies,  lexicons,  metrics,  and  metric  collection  processes; 
data  sources  supporting  establishment  of  causal  relationships  between  IO 
techniques  and  observed  effects;  and 
the  modeling  of  such  relationships, 

•  Intelligence  collection,  processing  and  dissemination,  with  particular  emphasis  on 
research  into: 

the  relationship  of  the  output  of  the  overall  intelligence  cycle  to  its  impact  upon 
the  warfighter  (ie.,  "sensor-to-shooter"  analyses),  as  well  as  issues  within  the 
intelligence  cycle  itself; 
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the  representation  of  "attributes"  which  can  be  sensed  by  ISR  sensors, 
emanating  from  targets,  decoys,  and  the  environment  (eg.  optical  signatures, 
thermal  signatures,  SAR  returns,  MTI  returns,  etc.);  and  the  structure,  contents 
and  availability  of  databases  relevant  to  the  authoritative  description  of  US  ISR 
capabilities  and  overall  opposing  force  systems,  processes  and  behaviours. 

A.5.11  Federation  Implementers  Forum  (IMPL) 

IMPL  addresses  hands-on  experience  in  developing  Federations,  particularly  lessons 
learned  from  using  the  latest  HLA-related  developments.  Present  areas  of  research  are: 

•  legacy  simulation  migration  to  HLA; 

•  SOM/FOM  interoperability; 

•  Federate/Federation  performance,  especially  WRT  large,  real-world  simulations; 

•  Federate/Federation  development  tools; 

•  exercise  execution  (eg.,  performance  issues  resulting  from  the  RTI);  and 

•  experiences  using  the  RTI,  especially  time  management,  data  distribution, 
ownership,  and  management. 

A.5.12  Vehicle/ Weapon  System  Modeling  Forum  (VWS) 

The  primary  focus  of  VWS  is  the  development  and  re-use  of  weapon/ vehicle  system 
simulations,  including  all  classes  of  manned  and  unmanned  weapon  and  vehicle 
systems  that  operate  in  space,  air,  ground,  and  sea  environments.  VWS  addresses  the 
representation  of  vehicle/ weapon  systems  in  constructive,  virtual,  and  live  simulations 
at  engineering,  engagement,  mission,  and  campaign  levels  of  aggregation. 

Present  areas  of  research  are: 

•  development  and  descriptions  of  weapon  system  or  vehicle  simulations; 

•  conversion  of  weapon  system  or  vehicle  simulations  from  DIS  to  HLA  compliance ; 

•  weapon  system  and  vehicle  Simulation  Object  Models  (SOMs),  model  and  data 
repositories,  and  class  taxonomies; 

•  methods  to  capture  the  "conceptual  models"  of  weapon  systems  or  vehicles  for  use 
in  simulation; 

•  standards  needed  to  enhance  the  representation  of  weapon  systems  or  vehicles 
within  simulation  federations; 

•  integration  of  weapon/ vehicle  systems  simulations/ simulators  in  acquisition 
processes; 

•  development  of  Distributed  Product  Descriptions  (DPDs),  Smart  Product  Models 
(SPMs),  or  Digital  System  Models  (DSMs)  that  portray  weapon/ vehicle  systems  in 
an  SB  A  environment; 

•  development  of  embedded  simulations  for  weapon/ vehicle  systems;  and 

•  simulations/simulators  for  advanced  weapons,  such  as  Directed  Energy  Weapons 
(DEW). 
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A.5.13  Behavior  Representation  Forum  (BEH) 

BEH  examines  the  realistic  representation  of  human  and  organizational  behavior 
within  models  and  simulations.  Present  areas  of  research  are: 

•  the  representation  of  behavior  within  IO-ISR,  SNE,  PROC,  TRAINING; 

•  validation  of  human  behaviour  models,  particularly  lessons  learned;  and 

•  extension/ amplification  to  the  concepts  related  to  a  standardized  format  for  the 
transmission  of  the  knowledge  base  component  of  a  reasoning  system. 

A.5.14  Logistics  Forum  (LOG) 

LOG  focusses  on  issues  related  to  logistics  simulation,  including  supply  chain  logistics, 
logistics  business  practices,  and  the  representation  of  logistics  systems  at  the  national, 
strategic,  operational,  and  tactical  military  levels.  Appropriate  aspects  of  coalition 
partner,  host  nation,  and/  or  non-military/ commercial  logistics  are  also  of  interest. 

Current  areas  of  specific  interest  are: 

•  lessons  learned  making  a  logistics  simulation  HLA-compliant  (including  issues  of 
object  ownership  transfer  and  aggregation/ deaggregation  of  data  used  by  systems 
of  different  levels  of  fidelity); 

•  integration  of  logistics  simulations  with  combat  simulations,  OOTW  tools,  C4ISR 
systems,  emergency  planning  systems,  or  other  logistics  systems; 

•  Simulation  Based  Acquisition  (SBA)  and  its  relationship  to  logistics,  such  as  the 
effect  of  acquisition  on  logistics  infrastructure,  supply  chain,  and  reliability;  and 

•  treatment  of  logistics  in  future  distributed  simulation  systems,  such  as  JSIMS, 
JWARS,  and  JMASS. 

A.5.15  Federation  Performance  Forum  (Fed_Perf) 

This  Forum  focuses  on  the  efficiency  and  effectiveness  of  Federation  performance. 
Present  topics  of  interest  are: 

•  metrics  for  characterizing  the  performance  of  individual  Federates,  composite 
Federations,  and  Rim-Time  Infrastructures  in  various  applications; 

•  scalability  of  Federation  performance  with  Federation  size  and  complexity; 

•  experiences  and  "lessons  learned"  from  those  who  have  built  and  optimized 
sizeable  Federations  for  practical  applications;  and 

•  tools  and  techniques  for  predicting  and  optimizing  the  performance  of  a  large, 
complex  Federation. 

A.5.16  Non-HLA  Environments  Forum  (Non-HLA) 

SIW  recognizes  that  many  distributed  simulations  have  different  types  of 
interoperability  protocols,  including  the  Distributed  Interactive  Simulation  (DIS) 
protocols  of  IEEE  Standard  1278,  Common  Object  Request  Brokering  Architecture 
(CORBA),  Web-based  simulations,  entertainment  oriented  protocols,  and  future 
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interoperability  protocols.  SIW  conferences  provide  an  opportunity  for  those  involved 
with  Non-HLA  interoperability  protocols  to  share  their  insights  and  issues  with  one 
another.  In  addition,  this  forum  has  a  focus  session  on  products  and  services  to  help 
migrate  users  of  DIS  to  HLA.  The  SIW  splits  this  forum  into  two  distinct  areas: 

•  DIS  related  topics:  products/ services,  lessons  learned,  new  programs  using  DIS, 
and  new  research  using  DIS;  and 

•  CORBA,  Web-based  simulations,  future  protocols,  etc. 

A.5.17  Real-time  Platform-level  Reference  Federation  Object  Model  Forum 

The  RPR  Virtual  Forum  deals  with  uses  of  and  extensions  to  the  Real-time  Platform- 
level  Reference  Federation  Object  Model  (RPR  FOM).  RPR  FOM  version  2.0  is  presently 
under  development. 

Current  topics  of  interest  to  this  forum  include: 

•  RPR  FOM  federation  implementations,  legacy  transitions  and  new  developments  - 
overview,  examples,  lessons  learned,  etc.; 

•  RPR  FOM  extensions,  implementation,  use,  and  the  requirements  that  necessitated 
the  additions;  and 

•  proposals  for  RPR  FOM  version  3.0  -  additions  and  modifications  that  fully  exploit 
HLA  functionality,  even  in  areas  not  supported  by  DIS. 

A.5.18  Simulation  Based  Acquisition  Forum  (SBA) 

This  forum  focuses  on  issues  and  approaches  for  achieving  consistent  representation 
and  interoperability  among  multiple,  distributed  models  and  simulations  used  in 
collaborative  environments  supporting  commercial  product  developments  and  system 
acquisition.  The  goal  is  to  develop  a  framework  for  identifying  candidate  SISO 
products  needed  to  support  this  application  domain. 

Topics  of  special  interest  include: 

•  operational  and  simulation  system  architectures  that  provide  a  frame  of  reference 
for  defining  interfaces,  interactions  and  economic  benefits  in  this  application 
domain; 

•  use  of  models  and  simulations  to  form  a  common  context  and  shared  environment 
enabling  collaboration  and  integration  among  end  users,  developers,  suppliers, 
supporting  systems,  service  providers  and  decision  makers;  and 

•  specifications  for  standardizing  model  and  data  descriptions,  interchange  formats 
and  repositories. 

A.5.19  Simulation  Interoperability  through  Components  Forum  (SITC) 

The  SITC  virtual  forum  addresses  the  use  of  component  technology  to  support 
simulation  interoperability.  In  particular,  the  following  topics  are  of  interest: 
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•  component  frameworks  for  supporting  simulation  interoperability,  including 
extensions  to  current  frameworks  and  simulation  interoperability  standards  to 
support  component  technology; 

•  components  for  simulation  design,  including  Base  Object  Models  (BOMs); 

•  metadata  for  components  to  support  the  characterization  of  components  and  their 
composition  as  part  of  a  simulation  system; 

•  components  for  simulation  implementations;  and 

•  management  issues  associated  with  simulation  component  use,  including: 
simulation  component  repositories,  W&A  and  testing  issues,  and  tool  support. 
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Appendix  B:  ISAG  Charter  and  List  of  Nations 

B.l.  AIM  OF  THE  ISAG 

1.  The  aim  of  the  ISAG  is: 

"To  provide  a  co-ordinating  focus  for  major  international  interests  in  the  work  on 
modelling  and  simulation  standards  being  carried  out  by  the  Simulation 
Interoperability  Standards  Organisation  (SISO)." 

B.2.  FURTHER  OBJECTIVES  OF  THE  ISAG 

2.  In  addition  the  ISAG  has  the  following  specific  objectives: 

a)  ensure  that  the  leadership  of  SISO  understands  the  specific  issues  and  concerns  of 
the  international  community  in  support  of  SISO's  goal  of  development  of  standards 
which  can  be  adopted  by  the  international  community; 

b)  ensure  that  SISO  understands  the  international  aspects  of  simulation 
interoperability  and  that  members  of  SISO  from  areas/nations/organisations  other 
than  the  US  understand  and  support  SISO  standards  so  that  they  can  promote  their 
adoption  as  local  standards  in  their  own  Area/Nation/Organisation  as  well  as  ISO. 

B.3.  APPOINTMENT  OF  NATIONAL  POINTS  OF  CONTACT 
(POCs) 

3.  Each  Area/ Nation/ Organisation  is  responsible  for  appointing  one  person  as  a 
Point  of  Contact  by  whatever  means  that  Area/ Nation/ Organisation  considers  is  the 
correct  mechanism.  It  is  recommended  that  within  his  Area/Nation/Organisation  the 
POC  has  connections  to  Government,  Industry  and  Academia. 

B.4.  APPOINTMENT  OF  CO-CHAIRMEN 

4.  There  will  be  six  Co-chairmen,  and  they  will  initially  (from  April  1997)  be  the  six 
National  POCs  from  Australia,  France,  Germany,  Sweden,  The  Netherlands  and  the 
United  Kingdom.  At  each  ITEC  Annual  Meeting,  there  will  be  a  vote  taken  during  die 
ISAG  meeting  to  appoint  the  six  Co-chairmen  for  the  following  year.  After  that  the 
places  for  two  Co-chairmen  will  be  open  for  voting  each  year. 

B.5.  MEMBERSHIP 

5.  The  membership  of  the  ISAG  is  open  to  any  person  or  company  belonging  to  an 
Area/ Nation/ Organisation  who  has  asked  to  be  associated  with  ISAG  and  who 
provides  a  POC. 
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B.6.  NATIONS  AND  ORGANISATIONS  ASSOCIATED  WITH 
ISAG 


1.  UK 

2.  Germany 

3.  France 

4.  The  Netherlands 

5.  Sweden 

6.  Australia 

7.  Austria 

8.  Belgium 

9.  Brazil 

10.  Canada 

11.  China 

12.  Chinese  Taipei 

13.  Croatia 

14.  Czech  Republic 

15.  Denmark 

16.  Estonia 

17.  Finland 

18.  Greece 

19.  Hungary 

20.  India 

21.  Israel 

22.  Italy 

23.  Japan 

24.  Latvia 

25.  Malaysia 

26.  Norway 

27.  Poland 

28.  Portugal 

29.  Romania 

30.  Russia 

31.  Singapore 

32.  Slovenia 

33.  South  Africa 

34.  Turkey 

35.  Ukraine 

36.  USA 


Co-chairman 
Co-  chairman 
Co-  chairman 
Co-  chairman 
Co-  chairman 
Co-  chairman 


Mr  Mick  Ryan 
Mr  Emst-Wichard  Budde 
Mr  Francois  Heran 
Dr  Hans  Jense 
Mr  Anders  Mattson 
Dr  Peter  Clark 


37.  European  Space  Agency  (ESA) 

38.  Society  for  Computer  Simulation  International  (SCS  (I)) 

39.  Eurocontrol 

40.  NATO 
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Appendix  C:  GLOSSARY  OF  TERMS  AND 

ACRONYMS 


NOTE:  Source(s)  quoted  after  each  entry. 

Accreditation.  An  official  certification  that  a  model  or  simulation  is  acceptable  for  use 
for  a  specific  purpose.  A  formal  authority  is  charged  with  approving  a  simulation  or 
simulator,  or  network  of  simulations/ simulators,  for  use  for  a  specific  purpose,  eg. 
training.  [C2] 

Accuracy.  The  degree  of  exactness  of  a  model  or  simulation,  relative  to  an  established 
standard,  high  accuracy  implying  low  error.  [C31] 

Advanced  Distributed  Simulation  (ADS).  A  synthetic  environment  within  which 
humans  may  interact  through  simulations  at  multiple  sites  networked  using  compliant 
architecture,  modelling,  protocols,  standards  and  databases.  [C29] 

Agent.  Software  that  has  the  properties  of  autonomy  (capable  of  independent 
functioning);  persistence  (continue  functioning  over  time);  and  proactive  and  reactive 
behaviour  (capable  of  goal  directed  behaviour  as  well  as  reactions  to  an  environment). 
Intelligent  agents  also  incorporate  reasoning,  learning  and  intelligence.  [C36] 

Aggregate.  An  activity  that  coalesces  individual  entities  into  a  singular  entity.  [C31] 

Aggregate  Level  Simulation  Protocol  (ALSP).  A  networking  architecture  allowing  the 
interoperability  of  constructive  simulations  (wargames). 

Aliasing.  The  name  given  to  a  wide  range  of  undesirable  visual  effects  caused  by  the 
quantisation  of  the  image  into  pixels.  Jagged  and/or  crawling  edges,  gaps  in  thin 
polygons  and  a  tendency  for  small  polygons  to  blink  on  and  off  are  typical  examples 
[C31] 


Analytical  Domain.  The  majority  of  simulation  models  are  employed  in  imitating  the 
behaviour  of  physical  systems  (such  as  aircraft  or  missiles)  which  do  not  require  or 
involve  interactive  human  input.  Simulations  which  require  the  aggregation  of  many 
systems  involving  human  behaviour  (such  as  air  combat)  may  employ  mathematical 
representations  of  human  operators  as  well  as  of  the  physical  systems.  These  models 
are  employed  in  the  systematic  study  of  the  behaviour  and  capabilities  of  complex 
systems.  [C35] 

Analytical  Model.  A  model  consisting  of  a  set  of  solvable  equations;  for  example,  one 
that  represents  the  laws  of  supply  and  demand  in  the  world  market.  [C31] 
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Anti-Aliasing.  Any  software  and/or  hardware  implementations  to  limit  aliasing. 
Normally  involves  super-sampling  the  image  and  averaging  the  results  into  the 
appropriate  number  of  pixels.  [C31] 

Architecture.  A  collection  of  interface  standards,  a  common  design  language,  and  a 
conceptual  framework  for  orienting  discourse  about  modelling  and  simulation  issues 
[C2],[C14] 

ATM.  Asynchronous  Transfer  Mode.  A  networking  standard  for  transmitting  at  high 
speeds  over  fiberoptic  cable.  [C6] 

Bandwidth.  A  measurement  of  the  amount  of  information  that  can  be  carried  over  a 
network  at  any  given  time.  [C39] 

BattleModel.  A  simulation  architecture  for  physical  entities  and  reasoning  models 
represented  by  tactical  decision  making.  The  reasoning  model  within  the  BattleModel 
is  dMARS  (distributed  Multi-Agent  Reasoning  System),  which  operates  under  a  BDI 
(beliefs,  desires,  intentions)  paradigm.  [C37] 

Broadcast.  An  addressing  mode  in  which  a  Protocol  Data  Unit  (PDU)  is  sent  to  all 
Distributed  Interactive  Simulation  (DIS)  nodes  on  a  network.  [C29] 

Built-In  Simulator.  A  simulator  that  is  built-in  to  the  system  being  modelled;  for 
example,  an  operator  training  simulator  built  into  the  control  panel  of  a  power  plant 
such  that  the  system  can  operate  in  simulator  mode  or  in  normal  operating  mode. 
Synonymous  with  embedded  training.  [C31] 

Certification:  Provides  formal  approval  of  the  validity  and  pedigree  of  a  data  set  for 
use  for  a  specific  purpose  [C2]. 

Client.  The  program  in  a  distributed  computing  system  that  does  the  requesting. 
Clients  direct  the  requests  to  servers  across  a  network.  They  wait  for  a  response  from 
the  server  indicating  that  the  request  is  complete.  [C6] 

Client/Server  Model.  The  model  of  interaction  in  a  distributed  system  in  which  a 
program  at  one  site  sends  a  request  to  a  program  at  another  site  and  then  awaits  a 
response.  The  requesting  program  is  called  the  client;  the  answering  program,  the 
server.  [C6] 

Collision  Detection.  A  process  available  in  some  image  generators  which  will 
determine  if  a  collection  of  test  points  (normally  representing  the  ownership)  have 
collided  with  objects  in  the  visual  database.  [C31] 
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Combat  Modelling.  Any  structured  activity  that  is  undertaken  to  represent  higher 
level  strategic  guidance,  doctrine  operational  concepts,  concepts  of  operation  and 
combat  scenarios  in  terms  of  varying  degrees  of  abstraction  and  reality.  [C30] 

Compatible.  Two  or  more  simulations/ simulators  are  DIS  compatible  if  they  are  DIS 
compliant,  and  their  models  and  data  that  send  and  interpret  PDUs  support  die 
realisation  of  a  common  operational  environment  among  the  systems  (coherent  in  time 
and  space).  [C31] 

Compliant.  A  simulation/ simulator  is  DIS  compliant  if  it  can  send  and  receive  PDUs 
in  accordance  with  IEEE  Standard  1278  and  1278  (Working  Drafts).  [C31] 

Computer  Aided  Learning  (CAL).  A  method  of  instruction  which  uses  computer 
technology  to  replace  traditional  text  and  classroom-based  teaching.  [C28] 

Computer  Generated  Forces  (CGF).  A  collection  of  unmanned  battlefield  entities 
under  control  as  a  unit.  CGF  replace  or  supplement  friendly,  enemy  or  neutral 
manned  simulators  during  a  specific  session.  If  a  platform  level  simulation  entity  is 
directly  controlled  by  a  man  in  the  loop  it  is  a  Semi- Automated  Force  (SAFOR),  if  it  is 
directly  controlled  by  a  computer  it  is  an  Automated  Force  (AFOR).  [C2] 

Computer  Generated  Imagery  (CGI).  The  actual  imagery  which  is  created  by  the 
computer  image  generation  process.  [C31] 

Configuration  Management.  The  application  of  technical  and  administrative  direction 
and  surveillance  to  identify  and  document  the  functional  and  physical  characteristics 
of  a  model  or  simulation,  control  changes,  and  record  and  report  change  processing 
and  implementation  status.  [C2] 

Constructive  Model  or  Simulation.  Models  and  simulations  that  involve  real  people 
making  inputs  into  a  simulation  that  carries  out  those  inputs  by  simulated  people 
operating  simulated  systems.  Wargames,  models  and  analytical  simulations  that 
typically  involve  aggregated  software  representations  of  units,  their  behaviour  and 
associated  outcomes.  [C2],  [C35] 

Control  Station.  Facility  which  provides  the  individual  responsible  for  controlling  the 
simulation  and  which  provides  the  capability  to  implement  simulation  control  as 
Protocol  Data  Units  (PDUs)  on  the  Distributed  Interactive  Simulation  network.  [C31] 

CSTT.  Combat  System  Team  Trainer.  The  acronym  denotes  the  ANZAC  ship 
operations  room  simulator  currently  under  development  for  use  at  HMAS  Watson 
[C33] 
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DARPA.  Defense  Advanced  Research  Projects  Agency.  Formerly  called  ARPA,  this  is 
an  agency  of  the  US  Department  of  Defense  (DOD).  It  was  the  original  funding  source 
for,  and  overseer  of,  TCP/IP.  [C6] 

Data.  Representation  of  facts,  concepts,  or  instructions  in  a  formalised  manner  suitable 
for  communication,  interpretation  or  processing  by  humans  or  automatic  means.  [C31] 

Database.  A  collection  of  data,  organised  according  to  a  schema  to  serve  one  or  more 
applications.  The  term  is  generally  applied  to  the  geometrical  information  which  the 
image  generator  will  process  to  produce  an  image.  As  a  minimum,  this  will  include 
polygons  which  are  defined  by  the  position  of  their  comers  (vertices)  and  some  method 
of  specifying  colour.  In  more  advanced  systems  the  database  will  be  in  a  hierarchical 
format  and  may  include  a  number  of  other  features  such  as  texture,  priority,  shading 
etc.  [C31] 

Database  Management.  The  process  by  which  the  real  time  system  in  the  image 
generator  can  bring  new  portions  of  the  database  from  the  system  disk  as  the  eyepoint 
moves  around  the  gaming  area.  The  new  data  is  taken  from  the  available  database  into 
the  active  database.  [C31] 

Data  Certification.  The  determination  that  data  have  been  verified  and  validated 
[C31] 

Data  Logger.  A  device  that  accepts  Protocol  Data  Units  (PDUs)  from  the  network  and 
stores  them  for  later  replay  in  the  same  time  sequence  as  the  PDUs  were  originally 
received. 

Data  Validation.  The  documented  assessment  of  data  by  subject  area  experts,  and  its 
comparison  to  known  or  best  estimate  values.  [C31] 

Data  Verification.  The  use  of  techniques  and  procedures  to  ensure  that  data  meet 
constraints  defined  by  data  standards  and  business  rules  derived  from  process  and 
data  modelling,  and  that  data  are  transformed  and  formatted  properly.  [C31] 

Data  Verification,  Validation,  and  Certification.  The  process  of  verifying  the  internal 
consistency  and  correctness  of  data,  validating  that  it  represents  real  world  entities 
appropriate  for  its  intended  purpose  or  an  expected  range  of  purposes,  and  certifying  it 
as  having  a  specified  level  of  quality  or  as  being  appropriate  for  a  specified  use,  type  of 
use,  or  range  of  uses.  [C31] 

Dead  Reckoning.  The  process  of  extrapolating  emulation  'entity'  position/ orientation 
based  on  the  last  known  position/ orientation,  velocity,  and  (sometimes)  higher-order 
derivatives  of  position  versus  time  and/or  other  vehicle  dynamic  characteristics.  [C31] 
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Defense  Communication  Agency  (DC A).  The  US  Government  agency  responsible  for 
installation  of  the  Defense  Data  Network.  [C6] 

Defense  Mapping  Agency  (DMA).  A  US  Government  agency  which  has 
responsibility  for  all  DoD  mapping  related  activities.  In  particular,  the  DMA  produces 
Digital  Radar  Land  Mass  Data,  Digital  Terrain  Elevation  Data  (DTED)  and  Digital 
Feature  Analysis  Data  (DFAD).  [C31] 

Defense  Modeling  and  Simulation  Office  (DMSO).  The  US  DOD  agency  responsible 
for  outlining  policy  and  strategic  direction  for  modeling  and  simulation  within  the  US 
military.  [C32] 

Defence  Simulation  Internet.  DMSO  sponsored  terrestrial  pipeline  (wide  band  packet 
switching)  for  the  distribution  of  simulations,  designed  to  be  the  test  bed  for  defence 
simulation  networking.  [C2] 

Distributed  Computing  Environment  (DCE).  A  set  of  technologies  selected  by  the 
Open  Software  Foundation  (OSF)  to  support  distributed  computing.  It  defines 
operating  system  elements,  Application  Programming  Interfaces  (APIs),  and  tools  that 
support  distributed  client/  server  computing  and  access  to  distributed  data.  [C6] 

DIS  Network  Manager.  A  specified  agency  with  the  responsibility  of  managing  the 
physical  network  which  connects  to  the  Distributed  Interactive  Simulation  (DIS) 
network.  Responsibilities  includes  approving/ accepting  DIS  participants,  scheduling 
of  DIS  utilisation,  establishing  network  priorities  for  DIS  applications,  monitoring 
execution  of  scheduled  usage,  and  co-ordinating  functional,  technical,  and  user 
communities'  network  requirements.  [C31] 

Disaggregate.  An  activity  which  decomposes  an  aggregate  entity  into  multiple 
entities.  [C31] 

Distributed  Interactive  Simulation.  (1)  Any  combination  of  virtual,  constructive,  and 
live  simulations  that  are  distributed  over  a  network  and  interact  through  standardised 
protocols.  (2)  IEEE  Standard  1278  protocols.  [C2]  The  term  "DIS"  is  often  used  in  the 
broader  context  of  the  definition  of  Advanced  Distributed  Simulation  More 
specifically,  DIS  may  be  specified  as  exact  protocols  such  as  DIS  2.0.4  (which  are  an 
IEEE  Standard).  [C29] 

E-mail  Electronic  Mail.  A  message-passing  application  that  runs  on  LANs  and  WANs. 
E-mail  enables  users  on  the  network  to  communicate  with  each  other.  [C6] 

Emulation.  A  simulation  methodology  in  which  all  three  elements  are  replicated  using 
software.  [C28] 
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Entity.  An  identifiable  individual  component  within  a  simulation.  An  entity  might  be 
a  platform  (ship,  submarine,  aircraft),  a  munition  (missile,  torpedo),  a  human  being,  or 
any  other  component  that  interacts  with  the  simulation.  [C29] 

Environment.  The  physical  surroundings  such  as  land,  sea,  air,  space  and  associated 
space-time  region  which  characterises  the  channel  or  conduit  for  real  interaction 
between  resources.  [Cl] 

Ethernet.  A  networking  architecture  for  LANs.  It  uses  a  bus  topology  and  was 
originally  designed  by  Xerox  Corp .  [C6] 

Exercise  Database.  A  Distributed  Interactive  Simulation  (DIS)  database  which 
includes  initialisation  data,  network,  simulation  entity,  environment  and  control  data 
[C31] 

Eyepoint.  The  point  in  space  from  which  the  image  calculates  its  image(s).  The  design 
eyepoint  is  the  physical  point  where  the  viewer's  head  is  expected  to  be.  [C31] 

Federation.  In  an  environment  consisting  of  a  collection  of  data/ knowledge  bases  and 
their  supporting  systems,  and  in  which  it  is  desired  to  accommodate  the  controlled 
sharing  and  exchange  of  information  among  the  collection,  the  individual 
(autonomous,  heterogeneous)  data/ knowledge  base  systems  are  termed  components, 
and  the  collection  of  components,  a  federation. 

Fidelity.  The  degree  to  which  aspects  of  the  real  world  are  presented  in  models  and 
simulators.  [C2] 

Field  Of  View  (FOV).  The  area  of  the  image  produced  by  the  visual  system,  normally 
expressed  as  a  horizontal  and  vertical  angle.  [C31] 

File  Transfer  Protocol  (FTP).  The  Internet  standard  for  transferring  files  from  one 
computing  device  to  another.  FTP  uses  the  TELNET  and  TCP  protocols.  [C6] 

Filtering.  Accepting  or  rejecting  Protocol  Data  Units  (PDUs)  received  on  the  network 
based  upon  specified  criteria,  which  may  be  dynamically  varied.  Examples  include 
geographical  filtering  and  entity  type  filtering.  [C31] 

Gateway.  A  networked  processor  that  routes  packets  of  data  between  two  or  more 
networks.  Sometimes  referred  to  in  the  context  of  internet.  [C6] 

Government  Network  Management  Profile  (GNMP).  Specifies  the  syntax  and 
semantics  of  the  management  information  needed  to  support  the  control  monitoring  of 
networks.  GNMP-compliant  products  can  be  separate  from  GOSIP-compliant 
products.  [C6] 
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Government  OSI  Profile  (GOSIP).  A  set  of  specifications  defining  OSI-compliance 
required  by  government  agencies  purchasing  networking  equipment.  [C6] 

Graphical  User  Interface  (GUI).  A  graphics-based  user  interface  that  incorporates 
icons,  pull-down  menus,  and  a  mouse.  GUIs  are  found  in  Macintosh,  Windows,  and 
OS/2  operating  systems.  [C6] 

Hardware.  A  non-reprogrammable  technology.  [Cl] 

Hardware-in-the-Loop  domain.  Simulations  that  involve  actual  hardware 
components  of  military  systems  (e.g.,  a  missile  seeker  head)  integrated  with 
simulations  of  the  other  components  of  the  overall  system.  [C35] 

Higher  Level  Architecture  (HLA).  An  object  oriented  approach  towards  simulator  and 
simulation  interoperability.  Currently  a  draft  IEEE  set  of  standards,  HLA  may  provide 
greater  interoperability  between  certain  networked  simulations,  and  increased 
interoperability  among  virtual,  live,  and  constructive  simulations.  [C39] 

Host  Computer.  A  computer  that  supports  one  or  more  simulation  applications.  All 
host  computers  participating  in  a  simulation  exercise  are  connected  by  a  common 
network.  [C31] 

Human  interactive  domain.  Includes  the  sub-categories  of  Live,  Virtual  and 
Constructive  simulation.  [C35] 

Hybrid  systems.  Systems  which  use  emulated  control  logic  and  real  hardware  for  the 
interface.  [C28] 

Image  Generator  (IG).  The  generic  term  which  refers  to  the  collection  of  hardware 
used  for  creating  computer  generated  imagery.  The  term  normally  implies  a 
significant  amount  of  special  purpose  hardware  and  real  time  operation.  [C31] 

Institute  of  Electrical  and  Electronics  Engineers  (IEEE).  A  US  based  organisation  that 
provides  the  accreditation  and  certification  of  various  standards.  The  latest  working 
version  of  DIS,  DIS  2.1.4,  is  enunciated  within  the  IEEE  standard  1278.1a.  [C6] 

Information.  A  set  of  conclusions  which  may  include  measures  of  uncertainty.  [Cl] 

Information  base.  An  implementation  where  information  is  represented  and  stored 
[Cl] 

Inheritance.  (In  Object  Oriented  Programming  (OOP)).  The  features  of  a  child  object 
which  may  be  attributed  to  a  parent  object.  [Cl] 
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Integrated  Services  Digital  Network  (ISDN).  A  type  of  wide-area  communication 
service  provided  by  long-distance  and  regional  telecommunications  service  providers 
[C6] 

Interface.  An  entity  of  a  composite  object  which  is  directly  responsible  for  its  observed 
attributes  and  behaviour.  [Cl] 

International  Standards  Organisation  (ISO).  A  worldwide  organisation  that  develops 
standards  in  all  product  areas.  ISO  is  responsible  for  defining  the  standard  for  the  OSI 
Reference  Model.  [C6] 

International  Simulation  Advisory  Group  (ISAG).  International  interest  and  reference 
group  concerning  modelling  and  simulation.  One  goal  is  to  provide  a  co-ordination 
focus  for  major  international  interests  in  M&S  standars  carried  out  by  SISO.  Website: 
www.isag.cx.  [C38] 

INTERNET.  A  worldwide  network  based  on  the  TCP/IP  protocol  suite  and  originally 
funded  by  DARPA.  [C6] 

Interoperability.  The  ability  of  simulations  to  provide  services  to  and  accept  services 
from  other  simulations  and  to  use  the  services  so  exchanged  to  enable  them  to  operate 
effectively  together.  Two  or  more  simulations/  simulators  are  DIS  interoperable  for  a 
given  exercise  if  they  are  DIS  compliant,  DIS  compatible,  and  their  performance 
characteristics  support  a  fair  fight  to  the  fidelity  required  for  the  exercise.  [C29] 

IOTTF.  Integrated  Operations  Team  Training  Facility.  Acronym  is  shown  in  figure  3 
in  Defence  Simulation  Master  Plan,  and  denotes  the  combined  DDG/FFG  ship 
operations  room  simulator  at  FIMAS  Watson.  [C33] 

Joint.  For  the  purpose  of  this  publication,  "joint"  refers  to  those  modelling  and 
simulation  items  and  activities  that  share  participation  or  support  of  more  than  one 
Service.  [C2] 

Latency.  The  portion  of  overall  transport  delay  (time)  which  is  in  excess  of  delays  in 
the  actual  vehicle  being  simulated.  [C31] 

Local  Area  Network  (LAN).  A  network  designed  to  connect  computers  and 
peripherals  over  relatively  short  distances.  Such  a  data  network  provides  a  high  data 
rate  interconnection  between  network  nodes  in  close  physical  proximity.  LANs  are 
defined  by  the  IEEE  802.X  series  of  standards.  [C2] 

Live  Simulation.  A  representation  of  military  operations  using  military  personnel  and 
equipment  which  simulate  experiences  achieved  during  actual  operational  conditions. 
Live  simulation  participants  perceive  the  environment  via  actual  sensors  or  directly 
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with  their  own  eyes.  [C2]  N.B.  The  authors  consider  that  live  simulation  is  a  subset  of 
training.  Not  all  training  is  simulation. 

Measure  of  Effectiveness  (MOE).  An  inherent  capability  parameter  which  can  only  be 
measured  in  the  course  of  accomplishing  a  mission.  [Cl] 

Measure  of  Performance  (MOP).  An  inherent  capability  parameter  which  may  be 
measured  independently  of  the  mission.  It  is  a  measure  of  how  the  system/ individual 
performs  its  functions  in  a  given  environment  (eg,  probability  of  detection,  reaction 
time,  number  of  targets  nominated).  [Cl] 

Mission  Rehearsal.  Practicing  planned  tasks  and  functions  critical  to  mission  success 
using  a  true-to-life,  interactive  representation  of  the  predicted  operating  environment 
[C2] 

Model.  A  physical,  mathematical,  or  otherwise  logical  representation  of  a  system, 
entity,  phenomenon,  or  process.  [C2] 

Modelling  and  Simulation  (M&S).  The  use  of  models,  including  emulators, 
prototypes,  simulations,  simulators,  and  stimulators,  either  statically  or  over  time,  to 
develop  data  as  a  basis  for  making  managerial  or  technical  decisions.  The  terms 
"modelling"  and  "simulation"  are  often  used  interchangeably.  [C35] 

Module.  A  generic  name  for  a  physically  or  functionally  aggregated  set  of  activities, 
processes,  services,  layers  or  resources  or  some  combination  thereof.  [Cl] 

Multicast.  A  transmission  mode  in  which  a  single  message  is  sent  to  multiple  network 
destinations,  i.e.  one-to-many.  [C31] 

Network  Filter.  A  system  of  network  addresses  to  selectively  accept  or  reject  Protocol 
Data  Units  received  from  the  network.  [C31] 

Node.  A  general  term  denoting  either  a  switching  element  in  a  network  or  a  host 
computer  attached  to  a  network.  [C31] 

OPC.  Offshore  Patrol  Combatant.  Acronym  is  shown  in  figure  3  in  Defence  Simulation 
Master  Plan,  and  denotes  the  possible  inclusion  of  a  future  OPC  ship  operations  room 
simulator  which  might  be  included  in  the  Maritime  Warfare  Training  Centre  Node  at 
HMAS  Watson.  [C33] 

Open  System  Environment.  The  fielding  of  hardware  and  software  products  that  are 
interoperable  and  portable.  The  objective  is  to  promote  competition  by  allowing 
systems  developed  by  multiple  vendors  and  nations  to  interoperate  through  a  common 
set  of  computer  and  communication  protocols.  [C2] 

Paradigm.  A  conceptual  model,  a  metaphor.  [Cl] 


71 


DSTO-GD-0255 


Platform.  A  generic  term  used  to  describe  a  level  of  representation  equating  to 
vehicles,  aircraft,  missiles,  ships,  fixed  sites,  etc.  in  the  hierarchy  of  representation 
possibilities.  Other  representation  levels  include  Units  (made  up  of  Platforms)  and 
components  or  modules  (which  make  up  Platforms).  [C31] 

Process.  A  set  of  interdependent  activities.  [Cl] 

Program.  An  executable  body  of  (computer)  code.  [Cl] 

Programmable.  Capable  of  being  encoded  to  execute  more  than  one  program.  [Cl] 

Proponent.  The  agency  or  organisation  that  has  primary  responsibility  for  the  life 
cycle  of  an  assigned  model  or  simulation.  [C2] 

Protocol.  A  set  of  rules  governing  a  data  communications  procedure  that  must  be 
followed  to  enable  two  or  more  computing  devices  to  exchange  and  read  instructions 
and  messages.  [C6] 

Protocol  Data  Unit  (PDU).  A  structured  message  which  transfers  essential  data  of  a 
specific  type  from  one  Distributed  Interactive  Simulation  (DIS)  entity  to  another  and 
allows  them  to  participate  in  a  common  exercise.  [C2] 

Prototype.  A  preliminary  type,  form,  or  instance  of  a  system  that  serves  as  a  Model  for 
later  stages  or  for  the  final,  complete  version  of  the  system.  [C31] 

Real  World.  The  set  of  real  or  hypothetical  causes  and  effects  that  simulation 
technology  attempts  to  replicate.  When  used  in  a  military  context,  the  term  is 
synonymous  with  Real  Battlefield  to  include  air,  land,  and  sea  combat.  [C31] 

Real  Time.  Simulated  time  with  the  property  that  a  given  period  of  actual  time 
represents  the  same  period  of  time  in  the  system  being  modelled.  [C31] 

Refresh  Rate.  The  rate  at  which  the  image  is  redrawn  on  the  display  device.  [C31] 

Resolution.  The  degree  of  detail  and  precision  used  in  the  representation  of  real  world 
aspects  in  a  model  or  simulation.  More  specifically,  resolution  is  used  as  a  measure  of 
the  ability  to  delineate  picture  detail.  [C2] 

Router.  A  device  or  system  used  to  connect  separate  LANs  and  WANs  into  an 
internetwork.  It  also  routes  data  traffic  between  the  networks  after  selecting  the 
transmission  path  or  paths.  Routers  were  called  gateways  during  the  early  years  of 
Internet  development.  [C6] 
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Server.  A  process  (also  the  computing  device  enabling  the  process)  in  a  distributed 
computing  system  that  provides  a  service  in  response  to  requests  from  client 
computing  devices.  [C6] 

Simple  Mail  Transfer  Protocol  (SMTP).  A  protocol  within  the  TCP/IP  protocol  suite 
used  to  transfer  mail  across  an  internet.  [C6] 

Simple  Network  Management  Protocol  (SNMP).  Part  of  the  TCP/IP  protocol  suite.  It 
enables  a  management  station  to  configure,  monitor,  and  receive  alarm  messages  from 
network  devices.  [C6] 

Simulation.  A  method  for  implementing  a  model  over  time  and  a  technique  for 
testing,  analysing,  or  training  in  which  real-world  systems  used,  or  real-world  and 
conceptual  systems  are  reproduced  by  a  model.  Most  combat  simulations  are 
implemented  as  computer  programs.  [C2],  adapted  from  [C6] 

Simulation  Based  Acquisition.  A  process  involving  an  integrated  application  of  M&S 
that  supports  military  systems  from  initial  concept  development  through  the 
acquisition  phase  to  in-service  support.  [C35] 

Simulation  Interoperability  Standards  Organisation  (SISO).  An  organisation 
dedicated  to  the  promotion  of  modelling  and  simulation  interoperability  and  re-use  for 
the  benefit  of  diverse  M&S  communities,  including  developers,  procurers,  and  users, 
world-wide.  SISO  provides  an  open  forum  that  promotes  the  interoperability  and  re¬ 
use  of  models  and  simulations  through  the  exchange  of  ideas,  the  examination  of 
technologies,  and  the  development  of  standards.  Website:  www.sisostds.org.  [C38] 

Simulator.  A  device  which  employs  simulation  to  replace  a  real  world  system  or 
apparatus,  eg  for  training  purposes.  A  simulator  generally  has  three  elements  -  a 
modelled  process  which  represents  the  real  world  system,  a  control  system,  and  a  man- 
machine  interface.  [C28] 

Software.  A  body  of  code  intended  for  programmable  hardware.  [Cl] 

State.  A  set  of  variables  which  characterise  object  entities  and  span  all  possible 
perspectives.  [Cl] 

Stimulation.  A  simulation  methodology  which  has  a  synthetic  environment 
generating  signals  which  are  input  to  the  real  control  system  and  which  uses  the  real 
hardware  interface.  [C28] 

Stochastic.  Pertaining  to  a  process,  model,  or  variable  whose  outcome,  result,  or  value 
depends  on  chance. 
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Synthetic  Environment.  Computer  generated  representation  of  the  real  world.  [C2], 
Most  often  used  to  recreate  a  virtual  battlefield  in  which  simulations  linked  via 
networks  can  conduct  and  fight  a  highly  realistic  battle.  [C29] 

Synthetic  Theatre  of  War  (STOW).  A  US  DoD  technology  demonstration  for  DIS 
within  an  operational  exercise.  STOW  was  proposed  by  the  US  Defence  Advanced 
Research  Projects  Agency  (DARPA)  to  provide  a  joint  virtual  theatre  of  war  for  up  to 
50  000  entities  by  1997.  It  was  planned  to  demonstrate  the  cost-effectiveness  of  using 
DIS  for  joint  warfare  training,  planning,  mission  rehearsal,  and  to  support  acquisition 
and  analysis  programs.  At  the  completion  of  the  project,  whilst  successful,  less  than 
10,000  entities  were  included.  [C29] 

TELNET.  The  TCP/IP  protocol  that  enables  a  terminal  attached  to  one  host  to 
establish  remote  terminal  connection  service.  It  is  the  application  that  allows  the  user 
to  connect  to  another  computer,  log  in,  and  start  a  remote  terminal  session.  [C6] 

Transmission  Control  Protocol  (TCP).  The  TCP/IP  protocol  that  provides  reliable, 
connection-oriented  data  transmission  between  a  pair  of  applications.  [C6] 

Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP).  The  only  major 
nonproprietary  protocol  suite  with  a  large  installed  base  world-wide.  It  was  developed 
under  the  guidance  of  the  US  Department  of  Defense  and  is  the  backbone  protocol  for 
the  Internet.  [C6] 

Unix.  An  operating  system  developed  at  AT&T  Bell  Laboratories  based  on  the 
principles  of  open  systems.  It  runs  on  a  wide  variety  of  computers,  and  has  been 
widely  acknowledged  as  the  optimal  operating  system  in  a  distributed  computing 
environment.  [C6] 

Validation.  The  process  of  determining  the  extent  to  which  a  model  or  simulation  is 
an  accurate  representation  of  the  real  world  from  the  perspective  of  the  intended  uses 
of  the  model  or  simulation.  [C2] 

Verification.  The  process  of  determining  that  model  or  simulation  implementation 
accurately  represents  the  developer's  conceptual  description  and  specifications. 
Verification  establishes  the  extent  to  which  the  model  or  simulation  has  been 
developed  using  sound  and  established  software  engineering  techniques.  [C2] 

Virtual  Modelling  and  Simulation.  A  simulation  involving  real  people  operating 
simulated  systems.  The  human-in-the-loop  in  virtual  simulations  has  a  central  role 
through  the  exercise  of  motor  control  skills  (e.g.,  flying  an  aircraft),  decision  skills  (e.g., 
committing  fire  control  resources  to  action),  or  communication  skills  (e.g.,  as  members 
of  a  C4I  team).  [C35] 
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Virtual  Reality.  A  group  of  technologies  which  provide  a  human  user  with  experience 
of  artificial  worlds  through  the  senses  of  vision,  sound,  touch  and  feel.  The 
technologies  consist  of  a  data  base  processed  by  a  computer  with  sophisticated 
graphics,  with  interaction  provided  by  a  head-set  or  helmet-mounted  display,  a  data 
glove,  and  a  head-tracking  position  sensor.  3D  audio  can  be  added,  and  a  number  of 
tactile  and  force  feedback  devices  are  under  development.  [C34] 

War  Games.  Manual  or  computer  simulations  with  human  players  making  some  or  all 
of  the  key  decisions.  War  games  are  themselves  models  in  that  they  attempt  to 
represent  a  system  (e.g.  the  nations  participating  in  war).  However,  they  also  require 
the  use  of  specialised  sub-models;  modem  war  games  typically  employ  interruptable 
or  highly  interactive  simulations,  with  the  opposed  players  making  periodic  decisions 
about  how  to  deploy  and  employ  forces.  These  decisions  are  entered  into  the  computer 
and  the  simulation  is  resumed.  A  few  war  gaming  models  can  be  used  interactively  in 
games  and  can  also  be  used  without  user  intervention,  as  closed  simulations,  by 
substituting  decision  models. 

Wide  Area  Network  (WAN).  A  network  connecting  computing  devices  and 
peripherals  over  long  distances.  The  transmission  medium  is  usually  a  long-distance 
carrier  but  can  also  be  a  private  dedicated  network.  [C6] 
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